[issue5364] documentation in epub format

[wrobell]

New submission from wrobell :

python documentation can be downloaded in pdf format (a4, us letter),
html and text plain. they are useful for printing and computer based
viewing, but not so good to read on ebook hardware/software
(i.e. sony prs-{505,700} or stanza ebook reader).

it would be nice if python documentation could be downloaded in epub
format, which is open format for ebooks

http://wiki.mobileread.com/wiki/EPUB
http://en.wikipedia.org/wiki/Epub#IDPF.2FEPUB
http://en.wikipedia.org/wiki/OEBPS

i believe that major publishers are providing ebooks in epub format
as well

http://newsbreaks.infotoday.com/wndReader.asp?ArticleId=52615

--
assignee: georg.brandl
components: Documentation
messages: 82698
nosy: georg.brandl, wrobell
severity: normal
status: open
title: documentation in epub format
type: feature request

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5364] documentation in epub format

[Senthil]

Senthil  added the comment:

I got into thinking if sphinx-dev or docutils be the best place for this ticket?

Python Documentation is nothing but ReStructured text and it is
required to create a rst2epub that would  convert restructured text to
epub format. If you are already aware of any such tool, please point
it to restructured text project for integration.

Python Bug tracker might be a wrong place for this feature request, IMO.

--
nosy: +orsenthil

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5365] add conversion table to time module docs

[Chris Rebert]

New submission from Chris Rebert :

I would like the offer the table in the attached file for addition to
the 'time' module documentation so as to provide a quick overview of how
to convert between the various time representations. As it currently
stands (at least on the current public version of the docs), to find the
same information, one must read through several nonadjacent prose
function descriptions, which can get tiring when one has to look up the
conversions repeatedly when writing a time-intensive program.

I'm new at the documentation format, but I think my submission is
reasonably correctly formatted; however, I don't have Sphinx to test
with, so I can't be 100% sure.

--
assignee: georg.brandl
components: Documentation
files: table.rst
messages: 82700
nosy: cvrebert, georg.brandl
severity: normal
status: open
title: add conversion table to time module docs
type: feature request
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file13172/table.rst

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5251] contextlib.nested inconsistent with, well, nested with statements due exceptions raised in __enter__

[Nick Coghlan]

Nick Coghlan  added the comment:

That's an interesting problem... since one of the things I like about
CMs is the ability to turn pretty much any block of code into a context
manager by substituting a yield statement at the appropriate point, not
having the ability to skip the yield is actually something of a hole in
the design.

This will need a bit of python-dev discussion, and may even turn into a
PEP (assuming we do go ahead with adding a SkipBlock exception and
modifying the with statement to check for it being raised by __enter__()
methods).

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5364] documentation in epub format

[wrobell]

wrobell  added the comment:

probably sphinx/docutils "deserve" their own tickets, but appropriate
tools support will not guarantee, that documentation in epub format is
going to be published on

http://docs.python.org/download.html

if documentation won't be published in this format, then i suggest
to close the ticket. but the decision is not up to me. :)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5364] documentation in epub format

[Senthil]

Senthil  added the comment:

On Wed, Feb 25, 2009 at 5:12 PM, wrobell  wrote:
> probably sphinx/docutils "deserve" their own tickets,

I agree with your points and I would wait for Georg's call on this ticket.

It would definitely help if you have already raised any tickets at
docutils or looked for a tool which does rst2epub.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2054] add ftp-tls support to ftplib - RFC 4217

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

> Actually I have encountered a possible bug. the close() 
> method doesn't seem to actually close the connection...

Why? What happens exactly?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I just took a quick look at Lib/abc.py and there's no way *I*'ll
reimplement it in C :)

The only workable approach would be:
1. rename the current would-be ABCs (IOBase, RawIOBase, etc.) with a
leading underscore (_IOBase, _RawIOBase, etc.)
2. call abc.ABCMeta() with the right arguments to create heap-types 
derived from those base types
3. call XXXIOBase.register() with each of the concrete classes
(BufferedReader, etc.) to register them with the ABCs created in 2

That is, do something like the following:

>>> IOBase = abc.ABCMeta("IOBase", (_io.IOBase,), {})
>>> RawIOBase = type("RawIOBase", (_io.RawIOBase, IOBase), {})
>>> RawIOBase.register(_io.FileIO)
>>> TextIOBase = type("TextIOBase", (_io.TextIOBase, IOBase), {})
>>> TextIOBase.register(_io.TextIOWrapper)

Which gives:
>>> f = open('foobar', 'wb', buffering=0)
>>> isinstance(f, RawIOBase)
True
>>> isinstance(f, IOBase)
True
>>> f = open('foobar', 'w')
>>> isinstance(f, IOBase)
True
>>> isinstance(f, TextIOBase)
True
>>> isinstance(f, RawIOBase)
False


As you see, RawIOBase inherits both from IOBase (the ABC, for ABC-ness)
and _RawIOBase (the concrete non-ABC implementation). Implementation
classes like FileIO don't need to explicitly inherit the ABCs, only to
register with them.

Also, writing a Python implementation still inherits the
close-on-destroy behaviour:

>>> class S(RawIOBase):
...   def close(self):
... print("closing")
... 
>>> s = S()
>>> del s
closing
>>> 

Perhaps we could even do all this in Python in io.py?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5366] examples for dependency keywords in setup.py

[anatoly techtonik]

New submission from anatoly techtonik :

When documentation grows too large it is nice to have clear examples
that stand out of text. Explanation is important to get the idea, but 
for a reference cookbook examples work better.

Here is a patch to clarify the usage of *requires* and *provides*
keywords in setup.py on the documentation page
http://docs.python.org/distutils/setupscript.html#relationships-between-distributions-and-packages


--- setupscript_old.txt Wed Feb 25 17:09:41 2009
+++ setupscript.txt Wed Feb 25 17:34:00 2009
@@ -423,6 +423,14 @@
 distribution being described.  If no qualifiers are given, all versions
of the
 named module or package are understood to be obsoleted.
 
+Example of using *requires* and *provides* keywords ::
+
+   setup(...,
+ requires=['dbm', 'foo=>1.1.0'],
+ provides=['myapi (1.1)'],
+)
+
+
 
 Installing Scripts
 ==

--
assignee: tarek
components: Distutils, Documentation
files: setupscript.diff
keywords: patch
messages: 82706
nosy: tarek, techtonik
severity: normal
status: open
title: examples for dependency keywords in setup.py
Added file: http://bugs.python.org/file13173/setupscript.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5367] typo in subprocess.py

[Joachim Ott]

New submission from Joachim Ott :

I saw it first in /usr/lib/python2.5/subprocess.py on two different
systems, line 12 reads:

r"""subprocess - Subprocesses with accessible I/O streams

It's still there in 3.0.1. Is a single "r" a valid python statement?

--
components: Library (Lib)
messages: 82707
nosy: ott--
severity: normal
status: open
title: typo in subprocess.py
versions: Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1580] Use shorter float repr when possible

[Preston Briggs]

Preston Briggs  added the comment:

In all this discussion, it seems that we have not discussed the
possibility of adapting David Gay's code, dtoa.c, which nicely handles
both halves of the problem.  It's also free and has been well exercised
over the years.

It's available here: http://www.netlib.org/fp/

It'd probably have to be touched up a bit.  Guido notes that, for
example, malloc is called without checking the return value. 
Nevertheless, the core is what we're looking for, I believe.

It's described in the paper: "Correctly rounded binary-decimal and
decimal-binary conversions", David M. Gay

It comes recommended by Steele and White (output) and by Clinger
(input), in the retrospectives on their seminal papers.

--
nosy: +preston

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5368] curses patch add color_set and wcolor_set functions

[Steve Owens]

New submission from Steve Owens :

Not sure what to set theType field to, this is my first patch 
submission.  The attached files are a unit test 
test_curses_color_set.py and the diff color_set_diff, apparently I can 
only attach one fo thetwo files.

--
assignee: georg.brandl
components: Documentation
files: color_set_patch.diff
keywords: patch
messages: 82709
nosy: georg.brandl, st...@integrityintegrators.net
severity: normal
status: open
title: curses patch add color_set and wcolor_set functions
versions: Python 2.7
Added file: http://bugs.python.org/file13174/color_set_patch.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5368] curses patch add color_set and wcolor_set functions

[Steve Owens]

Changes by Steve Owens :


Added file: http://bugs.python.org/file13175/test_curses_color_set.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1580] Use shorter float repr when possible

[Mark Dickinson]

Mark Dickinson  added the comment:

> It'd probably have to be touched up a bit.

This may be an understatement. :-)

In the first 50 lines of the 3897-line dtoa.c file, I see this warning:

/* On a machine with IEEE extended-precision registers, it is
 * necessary to specify double-precision (53-bit) rounding precision
 * before invoking strtod or dtoa.  [...] */

It seems to me that figuring out how and when to do this, and
writing and testing the appropriate configure/pyport/whatever
code, is already a nontrivial task.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1580] Use shorter float repr when possible

[Preston Briggs]

Preston Briggs  added the comment:

>> It'd probably have to be touched up a bit.

> This may be an understatement. :-)

Probably so.  Nevertheless, it's got to be easier
than approaching the problem from scratch.
And considering that this discussion has been
going on for over a year now, it might be a way to
move forward.

> In the first 50 lines of the 3897-line dtoa.c file, I see this warning:
>
> /* On a machine with IEEE extended-precision registers, it is
>  * necessary to specify double-precision (53-bit) rounding precision
>  * before invoking strtod or dtoa.  [...] */
>
> It seems to me that figuring out how and when to do this, and
> writing and testing the appropriate configure/pyport/whatever
> code, is already a nontrivial task.

I would consider compiling the library with flags appropriate to forcing
64-bit IEEE arithmetic if possible.  Another possibility is to explore
gdtoa.c
which is supposed to include code for extended precision, quad precision,
etc.

Added file: http://bugs.python.org/file13176/unnamed

___
Python tracker 

___>> It'd probably have to be touched up a 
bit.

> This may be an understatement. :-)Probably so.  Nevertheless, 
it's got to be easierthan approaching the problem from scratch.And 
considering that this discussion has beengoing on for over a year now, it 
might be a way to
move forward.
> In the first 50 lines of the 3897-line dtoa.c file, I see this 
warning:
> 
> /* On a machine with IEEE extended-precision registers, it is
>  * necessary to specify double-precision (53-bit) rounding precision
>  * before invoking strtod or dtoa.  [...] */
> 
> It seems to me that figuring out how and when to do this, and> 
writing and testing the appropriate configure/pyport/whatever
> code, is already a nontrivial task.
I would consider compiling the library with flags appropriate to 
forcing64-bit IEEE arithmetic if possible.  Another possibility is to 
explore gdtoa.cwhich is supposed to include code for extended precision, 
quad precision, etc.

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5369] __ppc__ macro checking is incorrect

[Arkadiusz Miskiewicz Arkadiusz Miskiewicz]

New submission from Arkadiusz Miskiewicz
Arkadiusz Miskiewicz :

Python/ceval.c and many other places rely on __ppc__ (and __ppc64__) 
symbol defined like below.

Unfortunately on my Linux ppc __ppc__ is never defined while 
__powerpc__ is. Build fortunately failed so the problem was noticed.

The fix is to check for __powerpc__ and __powerpc64__ as for example 
glibc does.



#if defined(__ppc__) /* <- Don't know if this is the correct symbol; 
this
   section should work for GCC on any PowerPC
   platform, irrespective of OS.
   POWER?  Who knows :-) */

--
messages: 82712
nosy: arekm
severity: normal
status: open
title: __ppc__ macro checking is incorrect
type: compile error
versions: Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Benjamin Peterson]

Benjamin Peterson  added the comment:

On Wed, Feb 25, 2009 at 10:15 AM, Antoine Pitrou  wrote:
>
> Antoine Pitrou  added the comment:
>
> I just took a quick look at Lib/abc.py and there's no way *I*'ll
> reimplement it in C :)

I don't blame you for that. :)

>
> The only workable approach would be:
> 1. rename the current would-be ABCs (IOBase, RawIOBase, etc.) with a
> leading underscore (_IOBase, _RawIOBase, etc.)
> 2. call abc.ABCMeta() with the right arguments to create heap-types
> derived from those base types
> 3. call XXXIOBase.register() with each of the concrete classes
> (BufferedReader, etc.) to register them with the ABCs created in 2

I think this is the best solution. We could also just move the Python
ABC's from _pyio to io.py and register() all the C IO classes, but
that would prevent the C implementation of IOBase from being used.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5229] Documentation for super() neglects to say what super() actually does

[Raymond Hettinger]

Raymond Hettinger  added the comment:

FWIW, I did a further update to the super docs to clarify that parent
classes are search in single inheritance models and that both parent and
siblings are searched in multiple inheritance models.  Made the concept
more concrete by relating pointing to the __mro__ attribute and by
comparing it to getattr() which also uses the __mro__.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5229] Documentation for super() neglects to say what super() actually does

[Raymond Hettinger]

Raymond Hettinger  added the comment:

See:  http://docs.python.org/dev/library/functions.html#super

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5367] typo in subprocess.py

[Benjamin Peterson]

Benjamin Peterson  added the comment:

The prefix "r" on a string makes it a raw string, certainly a valid
construct.

--
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5316] Buildbot failures in test_site

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Probably attached patch will fix this issue. But this patch doesn't
cover other similar problematic codes.

It seems this is multi inheritance problem. Following code shows B.setUp
and B.tearDown are called twice respectively. (In this issue, B
represents PyPIRCCommandTestCase)

class A(object): # LoggingSilencer
def setUp(self):
print "A setup"
super(A, self).setUp()
def tearDown(self):
print "A tearDown"
super(A, self).tearDown()

class B: # PyPIRCCommandTestCase
def setUp(self):
print "B setup"
def tearDown(self):
print "B tearDown"

class C(A, B): # sdistTestCase
def setUp(self):
A.setUp(self)
B.setUp(self)
def tearDown(self):
A.tearDown(self)
B.tearDown(self)

c = C()
c.setUp()
c.tearDown()

"""
A setup
B setup
B setup # called twice
A tearDown
B tearDown
B tearDown # ditto
"""

P.S. This is first time I saw the behavior of super in multi
inheritance. Movement of code flaw is interesting and fresh for me. :-)

--
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file13177/part_of_fix.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1580] Use shorter float repr when possible

[Mark Dickinson]

Mark Dickinson  added the comment:

> I would consider compiling the library with flags appropriate to forcing
> 64-bit IEEE arithmetic if possible.

Using the right compiler flags is only half the battle, though.  You 
should really be setting the rounding precision dynamically:  set it to 
53-bit precision before the call to strtod, and then restore it to 
whatever the original precision was afterwards.  And the magic formula for 
doing this is likely to vary from platform to platform.  As far as I can 
tell, the C99 standard doesn't suggest any standard spellings for changing 
the rounding precision.

It's not unknown for libm functions on x86 to blindly assume that the x87 
FPU is set to its default of extended-precision (64-bit) rounding, so it's 
risky to just set 53-bit rounding for the whole of Python's execution.

And contrary to popular belief, setting 53-bit rounding *still* doesn't 
give the x87 FPU IEEE 754 semantics:  there are issues at the extremes of 
the floating-point range, and I'm not 100% convinced that those issues 
wouldn't affect the dtoa.c strtod.

I'm not saying that all this is impossible;  just that it's subtle and 
would involve some work.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5283] setting __class__ in __del__ is bad. mmkay. negative ref count! kaboom!

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Could the PyObject_ClearWeakRefs(self); call in the middle of the lines 
del_changes_class.patch adds also be used to cause python code to set 
__del__ or __dict__ causing the wrong destructor or wrong dict to be 
DECREFed?

(I'm trying to wrap my head around the possibilities here and come up 
with a test case of that but weakref isn't behaving as i'd expect)

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5084] unpickling does not intern attribute names

[Jake McGuire]

Jake McGuire  added the comment:

Ugh.  Clearly I didn't check to see if it worked or not, as it didn't even 
compile.  A new diff, tested and verified to work, is attached.  I'll work 
on creating a test.

Added file: http://bugs.python.org/file13178/cPickle.c.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5084] unpickling does not intern attribute names

[Jake McGuire]

Changes by Jake McGuire :


Removed file: http://bugs.python.org/file12882/cPickle.c.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5084] unpickling does not intern attribute names

[Jake McGuire]

Changes by Jake McGuire :


Removed file: http://bugs.python.org/file13169/cPickle.c.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5370] unpickling vs. __getattr__

[Mike Meyer]

New submission from Mike Meyer :

The attached short file causes all of python 2.5, 2.6 and 3.0 to drop
into infinite recursion trying to unpickle the created object, but the
2.5 version has the cleanest The problem appears to be that the unpickle
code (C in 3.0; Python in 2.5 - I assume the others are similar) uses
getattr to try and get the __setstate__ method (if any) of the opject
being built before it's dictionary is populated. This causes the
invocation of the __getattr__ method, which tries to use the
non-existent "attrs" attribute, thus starting the recursion.

A simple workaround is to provide this:

  def __setstate__(self, data):
  self.__dict__.update(data)

but methinks that either 1) the interpreter shouldn't be falling into
the infinite loop in this case, or 2) the pickle code should be using
hasattr to check for the attribute (which won't trigger this problem)
before trying getattr on it.

--
files: pickletest.py
messages: 82721
nosy: mwm
severity: normal
status: open
title: unpickling vs. __getattr__
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13179/pickletest.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5371] Documentation of str.format in library/stdtypes shows incorrect first parameter

[Mitchell Model]

New submission from Mitchell Model :

In the library documentation of standard types, the instance method 
str.format is shown as taking a format-specification as its first 
argument. I'm pretty sure that this is incorrect. When format is called 
through a string, it is that string that is the format specification.

That is, shouldn't
format(format-specification-string, arg) be equivalent to
format-specification-string.format(arg)
?

--
assignee: georg.brandl
components: Documentation
messages: 82722
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of str.format in library/stdtypes shows incorrect first 
parameter
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5316] Buildbot failures in test_site

[Tarek Ziadé]

Tarek Ziadé  added the comment:

right, subclasses must use super if their superclasses do.

I'll apply Hirozaku patch (thanks). 

I might also simplify distutil base test class to avoid Mixins.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1580] Use shorter float repr when possible

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Even if someone devoted the time to get possibly get this right, it
would be somewhat difficult to maintain.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5316] Buildbot failures in test_site

[Tarek Ziadé]

Tarek Ziadé  added the comment:

applied in r69976 and r69977

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5229] Documentation for super() neglects to say what super() actually does

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Thanks!  These improvements are very helpful.  The one missing notion is
that "object-or-type" may be a proxy object, in which case super()
returns a new proxy that additionally skips "type".

Perhaps add the following sentence to the end of the first paragraph:
"If *object-or-type* is a proxy object, *super* returns a new proxy that
additionally skips *type*."

Also, I just spotted a typo.  In the following sentence, "in" should be
"it": "This makes in possible to implement “diamond diagrams” where
multiple base classes implement the same method"

Thanks, again!

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1580] Use shorter float repr when possible

[Guido van Rossum]

Guido van Rossum  added the comment:

What maintenance issues are you anticipating?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1580] Use shorter float repr when possible

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Gay's code is 3800+ lines and includes many ifdef paths that we need to
get right.  Mark points out that the code itself needs additional work.
 The discussions so far also get into setting compiler flags on
different systems and I would imagine that that would need to be
maintained as those compilers change and as hardware gets updated.  The
main challenge for a maintainer is to be sure that any change doesn't
break something.  AFAICT, this code is very difficult to validate.

The comments is the first 180 lines of code give a good survey of the
issues a maintainer would face when given a bug report in the form of:
eval(repr(f)) != f for myhardware x compiled with mycompiler c with
myflags f and running on operating system z.  There reports would be
even more challenging for cross-platform comparisons.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5229] Documentation for super() neglects to say what super() actually does

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Perhaps add the following sentence to the end of 
> the first paragraph: "If *object-or-type* is a proxy
>  object, *super* returns a new proxy that additionally
> skips *type*."

I'm not really sure what that even means.  Nor do I think
it was one of the use cases that Guido had in mind or is
tested in the unittest suite.

Is this something that has to be covered in the super() docs?
It seems like an implementation side-effect.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1580] Use shorter float repr when possible

[Tim Peters]

Tim Peters  added the comment:

The GNU library's float<->string routines are based on David Gay's. 
Therefore you can compare those to Gay's originals to see how much
effort was required to make them "mostly" portable, and can look at the
history of those to get some feel for the maintenance burden.

There's no difficulty in doing this correctly except for denormals.  The
pain is almost entirely in doing it correctly /fast/ -- and that is
indeed hard (which accounts for the extreme length and complexity of
Gay's code).

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5229] Documentation for super() neglects to say what super() actually does

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Actually, it's essential to how super() works.  Here's an example using
single inheritance:

class A(object):
  def foo(self):
print 'A'

class B(object):
  def foo(self):
super(B, self).foo()
print 'B'

class C(object):
  def foo(self):
super(C, self).foo()
print 'C'

x = C()
x.foo()

The "super" in x.foo() return a proxy for x that skips C.  
Next, we call foo() on that proxy, which calls B's foo().

In B's foo(), "self" is the proxy.  B's foo() passes the proxy to
super(), returning a new proxy for x that skips C and B.  Finally, we
call foo() on the new proxy, which calls A's foo().

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5229] Documentation for super() neglects to say what super() actually does

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

In the previous example, I meant to type

class B(A)

and

class C(B)

rather than having them all derive from object.  That's what I get for
not actually testing the code. ;-)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5229] Documentation for super() neglects to say what super() actually does

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I see what you mean but think that the docs shouldn't go into how
super() is implemented.  Already, they've reached an information density
such that adding more explanations will make it collectively less clear.
 As soon as you mention proxy objects as inputs, I'm pretty sure that
you've lost most of your readers (including me).  

I think what we've got is enough to help folks begin to understand what
to do even if they can't describe how super() is implemented.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5372] Distutils inappropriately reuses .o files between extension modules

[Collin Winter]

New submission from Collin Winter :

(Tarek, I've been told you're the new distutils maintainer. Feel free to
unassign this if that isn't the case.)

The test distutils uses to decide whether it needs to recompile an
existing .o file when building extension modules is too simplistic,
merely comparing the modification time of the .o and .c files. If you
have two extension modules like so

Extension('foo', ['foo.c', 'bar.c'],
  define_macros=[('NO_STATIC_MEMOTABLE', 1)])

Extension('bar', ['bar.c'])

even if defining NO_STATIC_MEMOTABLE=1 radically changes the code of
bar.c, distutils will use the same bar.o for both the foo and bar
extension modules. This was a real problem for me at work today.

The attached patch removes the modtime comparison entirely, preferring
to rebuild all .o files a given extension module needs. Note that while
_prep_compiler() isn't used anywhere in the stdlib, Google Code Search
turns up uses.

--
assignee: tarek
components: Distutils
files: ccompiler.patch
keywords: needs review, patch, patch
messages: 82734
nosy: collinwinter, jyasskin, tarek
severity: normal
stage: patch review
status: open
title: Distutils inappropriately reuses .o files between extension modules
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13180/ccompiler.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5371] Documentation of str.format in library/stdtypes shows incorrect first parameter

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r69987.

--
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1533164] Installed but not listed *.pyo break bdist_rpm

[Tarek Ziadé]

Changes by Tarek Ziadé :


Added file: http://bugs.python.org/file13181/rpm.ptch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1533164] Installed but not listed *.pyo break bdist_rpm

[Tarek Ziadé]

Changes by Tarek Ziadé :


Removed file: http://bugs.python.org/file13153/rpm.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Collin Winter]

Changes by Collin Winter :


--
nosy: +collinwinter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4715] optimize bytecode for conditional branches

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

Oh, and no problem with picking up the patches. Thanks for writing them
in the first place.

Here's the backport to trunk. I particularly enjoyed the bit in
pyassem.py where I had to teach the pure-Python compiler that you can
get to a block without going through a relative jump or a fallthrough.

The patch is also #2 at http://codereview.appspot.com/20064.

I'll post performance numbers as soon as I've measured them.

Added file: http://bugs.python.org/file13182/trunk-opt-cond-jump.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5362] Add configure option to disable Py3k warnings

[Collin Winter]

Collin Winter  added the comment:

Jeffrey: updated the patch to address your concerns.

Martin: I'm not sure I completely understand it either, though it seems
similar to issue4477. In the course of developing this patch, I tried
also #ifdef'ing out all usages of the Py_Py3kWarningFlag global. This
actually made things slower by around 5% across all the benchmarks I
tested. Could be pipeline stalls or a code size issue, I really don't know.

I'm not 100% convinced that something like this should go into CPython,
as a different compiler/hardware combination could well render it moot.
I mostly wanted a record of it, in case those few Python deployments
with homogeneous compilers/hardware across their machines that might
care about 1% better performance are interested.

Added file: http://bugs.python.org/file13183/no_py3k_warning.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5362] Add configure option to disable Py3k warnings

[Collin Winter]

Changes by Collin Winter :


Removed file: http://bugs.python.org/file13168/no_py3k_warning.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5362] Add configure option to disable Py3k warnings

[Collin Winter]

Collin Winter  added the comment:

Bah, forgot to run autoreconf. Fixed.

Added file: http://bugs.python.org/file13184/no_py3k_warning.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5362] Add configure option to disable Py3k warnings

[Collin Winter]

Changes by Collin Winter :


Removed file: http://bugs.python.org/file13183/no_py3k_warning.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Matthew Barnett]

Matthew Barnett  added the comment:

issue2636-features-4.diff includes:

Bugfixes
msg74203: duplicate capture group numbers
msg74904: duplicate capture group names

Added file: http://bugs.python.org/file13185/issue2636-features-4.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5332] csv sniffer

[Skip Montanaro]

Skip Montanaro  added the comment:

I verified the bug.  I started to work on a patch (see attached), but
it quickly seems to get out-of-hand with tracebacks about stuff not
supporting the buffer API.  I suspect the real solution might involve
doing something to convert the bytes to strings read when in binary mode,
but I don't have any idea how to finesse the requirement of bytes() for
an encoding arg.

--
keywords: +patch
nosy: +skip.montanaro
stage:  -> needs patch
versions: +Python 3.1
Added file: http://bugs.python.org/file13186/csv.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1006238] cross compile patch

[Mike Frysinger]

Mike Frysinger  added the comment:

Garrett: your configure method is overly complicated.  all you need to
do is set --build=binos_c3.4.3-p1.mips64-octeon-linux.  autoconf will
figure out all the other toolchain settings.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4715] optimize bytecode for conditional branches

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

The numbers are:

Intel Core 2, gcc-4.3, 32-bit
2to3:
25.24 -> 24.89: 1.38% faster

Django:
Min: 0.618 -> 0.607: 1.90% faster
Avg: 0.621 -> 0.615: 1.04% faster

PyBench:
Min: 5324 -> 5280: 0.83% faster
Avg: 5456 -> 5386: 1.30% faster

Pickle:
Min: 1.424 -> 1.376: 3.48% faster
Avg: 1.427 -> 1.378: 3.55% faster

Spitfire:
Min: 0.701 -> 0.718: 2.32% slower
Avg: 0.710 -> 0.721: 1.47% slower

Unpickle:
Min: 0.667 -> 0.651: 2.33% faster
Avg: 0.668 -> 0.652: 2.38% faster

Intel Core 2, gcc-4.3, 64-bit

2to3:
22.40 -> 22.59: 0.81% slower

Django:
Min: 0.575 -> 0.565: 1.74% faster
Avg: 0.577 -> 0.567: 1.76% faster

PyBench:
Min: 4332 -> 4433: 2.28% slower
Avg: 4393 -> 4519: 2.79% slower

Pickle:
Min: 1.177 -> 1.204: 2.25% slower
Avg: 1.180 -> 1.205: 2.14% slower

Spitfire:
Min: 0.622 -> 0.629: 1.22% slower
Avg: 0.623 -> 0.631: 1.26% slower

Unpickle:
Min: 0.576 -> 0.563: 2.25% faster
Avg: 0.596 -> 0.564: 5.55% faster


On my MacBook, gcc-4.0, 32-bit:
2to3:
29.82 -> 29.39: 1.46% faster

Django:
Min: 0.727 -> 0.720: 0.98% faster
Avg: 0.746 -> 0.736: 1.45% faster

PyBench:
Min: 6303 -> 6432: 2.01% slower
Avg: 6471 -> 6563: 1.40% slower

Pickle:
Min: 1.564 -> 1.564: 0.00% faster
Avg: 1.609 -> 1.592: 1.07% faster

Spitfire:
Min: 0.902 -> 0.909: 0.78% slower
Avg: 0.924 -> 0.920: 0.41% faster

Unpickle:
Min: 0.784 -> 0.763: 2.73% faster
Avg: 0.794 -> 0.776: 2.26% faster


The performance isn't as good as I'd like, especially on 64-bits. I
suspect the difference from the py3k branch is that trunk doesn't have
Antoine's dispatch patch, and POP_TOP is predicted after
JUMP_IF_{TRUE,FALSE}, which means without computed-goto-dispatch, this
patch usually only saves a predictable if(). The skipped JUMP_ABSOLUTEs
may not happen enough in my benchmarks to matter much.

On the other hand, "./python.exe -m timeit -s 'x=range(500)' '[y+3 for y
in x if y%5 <2]'" shows the following differences on my MacBook

For py3k:
Min: 196.000 -> 172.000: 13.95% faster
Avg: 200.000 -> 178.600: 11.98% faster
Significant (t=5.339997, a=0.95)

For trunk:
Min: 108.000 -> 88.200: 22.45% faster
Avg: 114.571 -> 97.571: 17.42% faster
Significant (t=5.518236, a=0.95)

That list comprehension definitely takes advantage of skipping the
JUMP_ABSOLUTE.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3585] pkg-config support

[Clinton Roy]

Clinton Roy  added the comment:

Oh, you meant for me to reply =)

- Do all unix-like system support pkg-config?

Yes. It even works on windows.

- Is $(LIBDIR)/pkgconfig the only choice for installing this file?

While pkg-config can be told to look in other directories for pc files
(via modifying the PKGCONFIGPATH env variable) it looks in
/usr/lib/pkgconfig by default, so that's where pc files should be put by
default.

- Shouldn't this file be installed only if the pkg-config utility is
present, or if the directory $(LIBDIR)/pkgconfig already exists?

Technically I suppose so, but I've not seen any package actually bother.

The patches I have made available are very similar to pkg-config
packages I've seen for many other packages.

cheers,

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1818] Add named tuple reader to CSV module

[Rob Renaud]

Rob Renaud  added the comment:

I am totally new to Python dev.  I reinvented a NamedTupleReader
tonight, only to find out that it was created a year ago.  My primary
motivation is that DictReader reads headers nicely, but DictWriter
totally sucks at handling them.

Consider doing some filtering on a csv file, like so.

sample_data = [
'title,latitude,longitude',
'OHO Ofner & Hammecke Reinigungsgesellschaft mbH,48.128265,11.610848',
'Kitchen Kaboodle,45.544241,-122.715728',
'Walgreens,28.339727,-81.596367',
'Gurnigel Pass,46.731944,7.447778'
]

def filter_with_dict_reader_writer():
  accepted_rows = []
  for row in csv.DictReader(sample_data):
if float(row['latitude']) > 0.0 and float(row['longitude']) > 0.0:
  accepted_rows.append(row)

  field_names = csv.reader(sample_data).next()
  output_writer = csv.DictWriter(open('accepted_by_dict.csv', 'w'),
 field_names)
  output_writer.writerow(dict(zip(field_names, field_names)))
  output_writer.writerows(accepted_rows)

You have to work so hard to maintain the headers when you write the file
with DictWriter.  I understand this is a limitation of dicts throwing
away the order information.  But namedtuples don't have that problem.

NamedTupleReader and NamedTupleWriter should be inverses.  This means
that NamedTupleWriter needs to write headers.  This should produce
identical output as the dict writer example, but it's much cleaner.

def filter_with_named_tuple_reader_writer():
   accepted_rows = []
   for row in csv.NamedTupleReader(sample_data):
 if float(row.latitude) > 0.0 and float(row.longitude) > 0.0:
   accepted_rows.append(row)

   output_writer = csv.NamedTupleWriter(
   open('accepted_by_named_tuple.csv', 'w'))
   output_writer.writerows(accepted_rows)

I patched on top of the existing NamedTupleWriter patch adding support
for writing headers.  I don't know if that's bad style/etiquette, etc.

--
nosy: +rrenaud
Added file: http://bugs.python.org/file13187/named_tuple_write_header.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1818] Add named tuple reader to CSV module

[Rob Renaud]

Rob Renaud  added the comment:

My previous patch could write the header twice.  But I am not sure about
about how the writer should handle the fieldnames parameter on one hand,
and the namedtuple._fields on the other.

Added file: http://bugs.python.org/file13188/named_tuple_write_header2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1818] Add named tuple reader to CSV module

[Rob Renaud]

Changes by Rob Renaud :


Removed file: http://bugs.python.org/file13187/named_tuple_write_header.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com