[ python-Bugs-1476845 ] Finish PEP 343 terminology cleanup

[SourceForge.net]

Bugs item #1476845, was opened at 2006-04-26 21:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Finish PEP 343 terminology cleanup

Initial Comment:
test_with.py was missed in the PEP 343 terminology
cleanup for Python alpha 2

PEP 343 itself still needs to be updated, too.

Creating this tracker item to record items needed to
finish the terminology cleanup post-alpha 2.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1476216 ] Documentation date stuck on "5th April 2006"

[SourceForge.net]

Bugs item #1476216, was opened at 2006-04-25 12:05
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476216&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mat Martineau (martineau)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Documentation date stuck on "5th April 2006"

Initial Comment:
My builds of the python documentation from the SVN
trunk have been stuck on "5th April 2006" for several
weeks now.

I've traced this to r43589, which hard-coded the date
in boilerplate.tex - this seems unusual, because
boilerplate.tex was not modified in this way for any
previous releases.

Seems like "\date{5th April 2006}" should be changed
back to "\date{\today}".

For some reason, the documentation at
http://docs.python.org/dev/ shows the correct date.


Mat


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-04-26 08:19

Message:
Logged In: YES 
user_id=11375

This change was made for the 2.5alpha1 release.  Undoing the
change probably just slipped the release manager's mind. 
The freeze for alpha2 is very soon, so this will probably
get fixed after alpha2 is out.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476216&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1475080 ] example code in what's new/sqlite3 docs

[SourceForge.net]

Bugs item #1475080, was opened at 2006-04-23 12:51
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475080&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James Pryor (jpryor68)
Assigned to: A.M. Kuchling (akuchling)
Summary: example code in what's new/sqlite3 docs

Initial Comment:
The documentation at


contains the following example code:


# Never do this -- insecure!
symbol = 'IBM'
c.execute("... where symbol = '%s'" % symbol)

# Do this instead
t = (symbol,)
c.execute('select * from stocks where symbol=?', ('IBM',))


The second block should instead read:


# Do this instead
t = ('IBM',)
c.execute('select * from stocks where symbol=?', t)



--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-04-26 08:25

Message:
Logged In: YES 
user_id=11375

Fixed in SVN; thanks for pointing this out.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475080&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1473048 ] SimpleXMLRPCServer responds to any path

[SourceForge.net]

Bugs item #1473048, was opened at 2006-04-19 11:45
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleXMLRPCServer responds to any path

Initial Comment:
SimpleXMLRPCServer and DocXMLRPCServer don't look at
the path of the HTTP request at all; you can POST or
GET from / or /RPC2 or /blahblahblah with the same results.

One minor problem with this liberality is that a
security scanner that looks for vulnerable scripts such
as /cgi-bin/phf will report the server as vulnerable. 
Nessus, for example, reports dozens of security holes
on a SimpleXMLRPCServer for this reason.

Fix: add a check that only allows '/' or '/RPC2' (maybe
just /RPC2?).



--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-04-26 08:42

Message:
Logged In: YES 
user_id=11375

The attached patch adds a .rpc_paths attribute that's a
tuple of legal paths, and a .is_rpc_path_valid() method that
returns True if a path is OK.

A .report_404() method generates a 404 error message, and
SimpleXMLRPCServer and DocXMLRPCServer are modified to check
for legal paths.  (Perhaps it should be ._report_404?)


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1476356 ] StringIO should implement __str__()

[SourceForge.net]

Bugs item #1476356, was opened at 2006-04-25 16:11
Message generated for change (Comment added) made by cinamod
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Dom Lachowicz (cinamod)
Assigned to: Nobody/Anonymous (nobody)
Summary: StringIO should implement __str__()

Initial Comment:
I was a bit surprised when I discovered that StringIO
didn't have a __str__() method, equivalent to
getvalue(). Calling str(stringio_object) gives the
following:

>>> import StringIO
>>> s = StringIO.StringIO("hello world")
>>> print "%s" % (str(s))


I had some (perhaps dodgy code) code that did:

if isinstance(data, types.FileType):
  return data.read()
else:
  return str(data)

Since StringIO doesn't subclass any file type and
doesn't implement a __str__() method, I was getting
seemingly bogus results. This was trivially worked
around by adding another "isinstance(data,
StringIO.StringIO)" case, but it was surprising
nonetheless. Thanks.

--

>Comment By: Dom Lachowicz (cinamod)
Date: 2006-04-26 11:09

Message:
Logged In: YES 
user_id=69417

Since section 2.3.9 of the docs doesn't mention anything
about an overriden meaning of FILE.__str__(), its meaning in
that API is undefined. "Correctly emulating" undefined API
is impossible.

--

Comment By: Dom Lachowicz (cinamod)
Date: 2006-04-25 22:54

Message:
Logged In: YES 
user_id=69417

The StringIO API diverges from the file API already. It adds
API (getvalue()) doesn't implement the encoding, mode, name,
newlines, or softspace attributes, and implements isatty()
in violation of the section 2.3.9 docs.

In some contexts, it may look like a file, but it isn't a
file. And I don't see how implementing __str__() changes
that. It's equivalent to saying that Java's StringBuffer
class shouldn't override toString()...

--

Comment By: Dom Lachowicz (cinamod)
Date: 2006-04-25 22:53

Message:
Logged In: YES 
user_id=69417

The StringIO API diverges from the file API already. It adds
API (getvalue()) doesn't implement the encoding, mode, name,
newlines, or softspace attributes, and implements isatty()
in violation of the section 2.3.9 docs.

In some contexts, it may look like a file, but it isn't a
file. And I don't see how implementing __str__() changes
that. It's equivalent to saying that Java's StringBuffer
class shouldn't override toString()...

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-04-25 18:58

Message:
Logged In: YES 
user_id=80475

This isn't a bug.  The module is correctly emulating the API
for file objects.

I recommend replacing your isintance() test with a try/except:

try:
 return data.read()
except AttributeError:
 return str(data)



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1477102 ] Missing import line in example

[SourceForge.net]

Bugs item #1477102, was opened at 2006-04-26 10:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477102&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Eckel (bruceeckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing import line in example

Initial Comment:
11.22.9 Example of Client Usage 

Should include the following import line:
from xmlrpclib import ServerProxy

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477102&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1477140 ] Incorrect code in example

[SourceForge.net]

Bugs item #1477140, was opened at 2006-04-26 11:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477140&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Eckel (bruceeckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect code in example

Initial Comment:
In
11.22.9 Example of Client Usage 
The line:
except Error, v:
should probably be:
except Exception, v:

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477140&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1391608 ] missing module names in email package

[SourceForge.net]

Bugs item #1391608, was opened at 2005-12-27 21:04
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Gabriel Genellina (gagenellina)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: missing module names in email package

Initial Comment:
Documentation for modules inside the email package 
lacks reference to module name in title (and body too).
By example, there is no clue in 12.2.1 that the Message 
class being described is contained in the email.Message 
module. Or 12.2.2 doesnt menction that FeedParser, 
HeaderParser and Parser are all classes contained in 
module email.Parser. And so on.

Looking at other similar standard packages (like 
curses) seems that the module name should appear first 
in the title.


--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-26 19:16

Message:
Logged In: YES 
user_id=3066

Assigned to the email tsar.  This is complicated by the
dual-naming approach for Python 2.5.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError

[SourceForge.net]

Bugs item #1386675, was opened at 2005-12-20 20:41
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
>Assigned to: Mark Hammond (mhammond)
Summary: _winreg specifies EnvironmentError instead of WindowsError

Initial Comment:
The _winreg documentation says that EnvironmentError
will be raised (throughout the docs, for various
reasons), when, in every case, WindowsError is actually
raised.

A simple replace of WindowsError for EnvironmentError
would fix this.  (Let me know if you really need a patch).

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-26 19:19

Message:
Logged In: YES 
user_id=3066

Assigning to Mark Hammond since he should be able to tell us
what the docs *should* say, and why.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-27 12:26

Message:
Logged In: YES 
user_id=1188172

You're right. I reverted the checkin, assigning to Fred.

--

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-27 03:08

Message:
Logged In: YES 
user_id=38376

The original checkin used EnvironmentError in both
the documentation and the docstrings, so this is not
a result of some accidental editing.  Since a good
documentation policy for a portable language is to
document intended usage, not implementation artifacts,
you should at least check with the original authors
before you make the documentation depend on the current
CPython implementation.

(and no, using EnvironmentError is an entirely different
thing than using Exception.  Can we keep the hyperbolic
arguments on comp.lang.python, please?)

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-26 19:03

Message:
Logged In: YES 
user_id=1188172

Corrected in rev. 41829/41830.

--

Comment By: Tony Meyer (anadelonbrin)
Date: 2005-12-25 21:36

Message:
Logged In: YES 
user_id=552329

I don't see what purpose there is in having the
documentation say that EnvironmentError is raised, when a
subclass is.  _winreg is still marked as a temporary module
to be replaced, so it's hard to believe it's some sort of
future-proofing.

One could say that Exception is raised, since
EnvironmentError is a subclass of Exception, but explicit is
better than implicit, right?

(import _winreg fails on non-Windows platforms, so I don't
see how it could be for cross-platform reasons, either).

--

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-25 06:44

Message:
Logged In: YES 
user_id=38376

however, note that

>>> issubclass(WindowsError, EnvironmentError)
True

on windows, and

>>> issubclass(WindowsError, EnvironmentError)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'WindowsError' is not defined

on non-windows platforms, so it might be done this way
on purpose.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1124692 ] Math mode not well handled in \documentclass{howto}

[SourceForge.net]

Bugs item #1124692, was opened at 2005-02-17 08:08
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124692&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Daniele Varrazzo (dvarrazzo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Math mode not well handled in \documentclass{howto}

Initial Comment:
LaTeX loses its Math Magic (tm) when using 
\documentclass{howto}: underscore operator in math 
enviroment doesn't produce subscripts.

This documents shows some oddities:

\documentclass{howto}

\begin{document}

Water is $H_2O$, and subscript is missing from...

\[ V_{0,r} \]

Superscripts are instead fine, as $e^{\pi i} + 1 = 0$ 
shows.

Also this is completely different from what obtained by
\textbackslash documentclass\{article\}.

\[ \sum_{k=0}^\infty \int_0^k f(x) dx \]
\end{document}

The bug is removed by commenting out lines 541--549 in 
python.sty, but i don't know how to *fix* them... (not a 
TeXpert)

Using Python 2.3.5, Windows 2000, LaTeX2e (e-TeX 
3.141592-2.2, MikTex 2.4 implementation)

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-26 19:30

Message:
Logged In: YES 
user_id=3066

Boy, has this lingered!

Everything seems to be fine with the current version using
your example docuement, so I'm closing this as out of date.

Please respond if you're still having trouble with the
latest version.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124692&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-839709 ] Windows non-MS compiler doc updates

[SourceForge.net]

Bugs item #839709, was opened at 2003-11-10 21:47
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Windows non-MS compiler doc updates

Initial Comment:
Documents affected:

http://www.python.org/doc/2.3.2/inst/tweak-flags.html 
sec. 6.2.2
http://www.python.org/doc/2.3.1/inst/tweak-flags.html 
sec. 6.2.2
http://www.python.org/doc/2.3/inst/tweak-flags.html 
sec. 6.2.2
http://www.python.org/doc/2.2.3/inst/non-ms-
compilers.html sec. 3.1.2
http://www.python.org/doc/2.2.2/inst/non-ms-
compilers.html sec. 3.1.2
http://www.python.org/doc/2.2.1/inst/non-ms-
compilers.html sec. 3.1.2
http://www.python.org/doc/2.2/inst/non-ms-
compilers.html sec. 3.1.2
http://www.python.org/doc/2.1.3/inst/non-ms-
compilers.html sec. 3.1.2
http://www.python.org/doc/2.1.2/inst/non-ms-
compilers.html sec. 3.1.2
http://www.python.org/doc/2.1.1/inst/non-ms-
compilers.html sec. 3.1.2
http://www.python.org/doc/2.1/inst/tweak-flags.html 
sec. 3.1.2

1. Filenames in the examples are way out of date. It is 
also not clear to the reader that python23.dll is located 
in %SystemRoot%\System32. I suggest that you change 
the pexports command line example to

pexports \Windows\System32\python23.dll > 
python23.def

In the Python 2.2 docs, use python22.dll and 
python22.def. In the Python 2.1 docs, use python21.dll 
and python21.def.

2. It's not clear to the reader where dlltool is. dlltool can 
also output directly to the right directory. I suggest that 
you change the dlltool command line example to

\cygwin\bin\dlltool --dllname python23.dll --def 
python23.def --output-lib \Python23\Libs\libpython23.a

In the Python 2.2 docs, use python22.dll, python22.def, 
and libpython22.a. In the Python 2.1 docs, use 
python21.dll, python21.def and libpython21.a.

3. Another filename out of date. I suggest that you 
change "The resulting library has to be placed in the 
same directory as python20.lib." to "The resulting library 
has to be placed in the same directory as python23.lib."

In the Python 2.2 docs, use python22.lib. In the Python 
2.1 docs, use python21.lib.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-26 20:04

Message:
Logged In: YES 
user_id=3066

--sigh--

I guess I've not had a lot of time for the past few years.  :-(

Luckily, most of this has already been handled for newer
releases.  I've made updates based on 1 and 2 for the Python
2.5 documentation (revision 45738).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-624827 ] Creation of struct_seq types

[SourceForge.net]

Bugs item #624827, was opened at 2002-10-17 14:51
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624827&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Creation of struct_seq types

Initial Comment:
It would be really nice to be able to create structure
sequence types from within Python.  MvL suggested:
---
... I think all you need to do is to expose
PyStructSequence_InitType. I would recommend an
interface like

struct_seq(name, doc, n_in_sequence, (fields))

where fields is a list of (name,doc) tuples. You will
need to temporarily allocate a PyStructSequence_Field
array of len(fields)+1 elements, and put the
PyStructSequence_Desc on the stack. You will also need
to dynamically allocate a PyTypeObject which you return.

I would put this into the new module.
---
Assigned to me since I actually wanted to create these
things.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-26 20:08

Message:
Logged In: YES 
user_id=3066

I'm not going to have any time to look at this; hopefully
somebody else can, since it's a pretty reasonable idea I
think.  It may not be as valuable as it once was, however
(subclassing tuple and using properties has become more
attractive using an @property decoration).

--

Comment By: Eric Huss (ehuss)
Date: 2004-06-25 21:13

Message:
Logged In: YES 
user_id=393416

Uploaded patch 980098 which implements this functionality as 
a separate module.


--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-22 16:26

Message:
Logged In: YES 
user_id=3066

As part of this, struct_seq types should be made subclassable.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624827&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1411674 ] "print statement" in libref index broken

[SourceForge.net]

Bugs item #1411674, was opened at 2006-01-21 14:50
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411674&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: "print statement" in libref index broken

Initial Comment:
The "print statement" entry in the libref index refers the user to

   http://www.python.org/dev/doc/devel/lib/types.html#l2h-92

The source (libstdtypes.tex):

   \ulink{\keyword{print} statement}{../ref/print.html}

suggests that the link should be to the reference manual.  Something's
fishy.  This was reported on comp.lang.python by
[EMAIL PROTECTED]  His report was against the current doc, but
the problem still exists in the development version.

Just passing it along...


--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-26 20:14

Message:
Logged In: YES 
user_id=3066

I think it's reasonable.  It's about the fact that print
uses the str() function, so it's clearly about the print
statement.  This information is good to have linked from the
index, I think.

No need to change anything.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-21 14:59

Message:
Logged In: YES 
user_id=1188172

The output is okay. The \ulink you state does not add the
index entry, it's the \stindex one line above it.

But it's questionable whether this mention of print merits
an index entry. Fred?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411674&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com