[issue1040026] os.times() is bogus

2008-02-29 Thread Hirokazu Yamamoto

Hirokazu Yamamoto added the comment:

How abount also check CLK_TCK? I know it's obsolute but maybe
there are platforms without sysconf() and with CLK_TCK.

--
nosy: +ocean-city

_
Tracker <[EMAIL PROTECTED]>

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



[issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path

2008-02-29 Thread Raghuram Devarakonda

Raghuram Devarakonda added the comment:

>  Should it get a _ prepended to it then?

Probably yes.

__
Tracker <[EMAIL PROTECTED]>

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



[issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path

2008-02-29 Thread Benjamin Peterson

Benjamin Peterson added the comment:

Should it get a _ prepended to it then?

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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



[issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path

2008-02-29 Thread Raghuram Devarakonda

Raghuram Devarakonda added the comment:

On Fri, Feb 29, 2008 at 9:21 PM, Joseph Armbruster
<[EMAIL PROTECTED]> wrote:
>  On another note, I just completed building the docs in windows and
>  shutil.destinsrc does not appear to be documented.  I did notice this
>  description for shutil:

destinsrc() is an internal function used only in shutil.move().

__
Tracker <[EMAIL PROTECTED]>

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



[issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path

2008-02-29 Thread Joseph Armbruster

Joseph Armbruster added the comment:

On another note, I just completed building the docs in windows and
shutil.destinsrc does not appear to be documented.  I did notice this
description for shutil:

"The shutil module offers a number of high-level operations on files and
collections of files. In particular, functions are provided which
support file copying and removal."

I would have expected to find a function like this in os.path, not shutil.

__
Tracker <[EMAIL PROTECTED]>

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



[issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path

2008-02-29 Thread Joseph Armbruster

Joseph Armbruster added the comment:

Using:  http://svn.python.org/projects/python/trunk  @  61127
OS Name:Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 2 Build 2600

test_shutil
1 test OK.

--
nosy: +JosephArmbruster

__
Tracker <[EMAIL PROTECTED]>

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



[issue1451466] reading very large files

2008-02-29 Thread Joseph Armbruster

Joseph Armbruster added the comment:

I believe this may be related to issue 1672853.

http://bugs.python.org/issue1672853

--
nosy: +JosephArmbruster

_
Tracker <[EMAIL PROTECTED]>

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



[issue1672853] Error reading files larger than 4GB

2008-02-29 Thread Joseph Armbruster

Joseph Armbruster added the comment:

Using: http://svn.python.org/projects/python/trunk  @  61127
OS Name:Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 2 Build 2600

I would like to report a positive follow-up on this issue.  The output I
received was as follows, indicating this specific issue may be resolved.
 The resulting bigfile produced from the test totaled 11.5 GB
(12,382,502,912 bytes).

python bigfiletest1.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

--
nosy: +JosephArmbruster, tiran

_
Tracker <[EMAIL PROTECTED]>

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



[issue2213] build_tkinter.py does not handle paths with spaces

2008-02-29 Thread Joseph Armbruster

New submission from Joseph Armbruster:

http://svn.python.org/projects/python/trunk/PCbuild/build_tkinter.py
rev 61127

Is it still in python-devs interest to support building the tree in a
path that contains spaces?  I (pretty much always) do, so if a patch for
this is desired, I can put one together.

--
components: Build, Windows
messages: 63152
nosy: JosephArmbruster, tiran
severity: normal
status: open
title: build_tkinter.py does not handle paths with spaces
type: behavior
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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



[issue2196] Fix hasattr's exception problems

2008-02-29 Thread Brett Cannon

Brett Cannon added the comment:

On Fri, Feb 29, 2008 at 2:04 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
>  Benjamin Peterson added the comment:
>
>  After looking more closely, I saw that this is documented at
>  http://www.python.org/dev/patches/style/. So the C uses tabs, and the
>  Python uses spaces?

Yes, although that is changing in Python 3.0.

--
nosy: +brett.cannon

__
Tracker <[EMAIL PROTECTED]>

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



[issue2195] urlparse() does not handle URLs with port numbers properly

2008-02-29 Thread Gawain Bolton

Gawain Bolton added the comment:

On the contrary, RFC 1738 does mention the port number in section 3.1. 
Common Internet Scheme Syntax:

   While the syntax for the rest of the URL may vary depending on the
   particular scheme selected, URL schemes that involve the direct use
   of an IP-based protocol to a specified host on the Internet use a
   common syntax for the scheme-specific data:

//:@:/

   Some or all of the parts ":@", ":",
   ":", and "/" may be excluded.  The scheme specific
   data start with a double slash "//" to indicate that it complies with
   the common Internet scheme syntax.

I agree with Christos Georgiou's suggestion that if the a default 
scheme is passed AND the default scheme is a URL scheme, then the 
scheme should be identified as being before "://".

__
Tracker <[EMAIL PROTECTED]>

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



[issue2211] Cookie.Morsel interface needs update

2008-02-29 Thread Martin v. Löwis

Martin v. Löwis added the comment:

Would you be interested to work on a patch?

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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



[issue2199] cPickle error with gtk GEnum classes

2008-02-29 Thread Martin v. Löwis

Changes by Martin v. Löwis:


--
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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



[issue2199] cPickle error with gtk GEnum classes

2008-02-29 Thread Paul Pogonyshev

Paul Pogonyshev added the comment:

Please close this issue.  It is a PyGObject bug, nothing to do with
Python: http://bugzilla.gnome.org/show_bug.cgi?id=519645

__
Tracker <[EMAIL PROTECTED]>

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



[issue2196] Fix hasattr's exception problems

2008-02-29 Thread Benjamin Peterson

Benjamin Peterson added the comment:

After looking more closely, I saw that this is documented at
http://www.python.org/dev/patches/style/. So the C uses tabs, and the
Python uses spaces?

Added file: http://bugs.python.org/file9576/hasattr_fixes-good-indentation.diff

__
Tracker <[EMAIL PROTECTED]>

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



[issue1766304] improve xrange.__contains__

2008-02-29 Thread Alexander Belopolsky

Alexander Belopolsky added the comment:

Here are my comments on the py3k patch:

1. Sign of a PyLong object o is the same as the sign of Py_SIZE(o).  I 
would think it is safe to use this fact within python core.  (User code 
that may need to work across multiple versions of python may need to be 
more conservative.)

2. If you choose to use zero in the code, there is no need to create it 
twice per call.

3. Py_INCREF(zero); is unnecessary and creates a reference leak.

4. range_contains should return -1 when error is detected, not 0.

2.

_
Tracker <[EMAIL PROTECTED]>

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



[issue2212] Cookie.BaseCookie has ambiguous unicode handling

2008-02-29 Thread Jamie Bliss

New submission from Jamie Bliss:

The primary offender is in BaseCookie.load(), which uses the test:
type(rawdata) == type("")
which should be:
isinstance(rawdata, basestring)

--
components: Library (Lib)
messages: 63145
nosy: astronouth7303
severity: normal
status: open
title: Cookie.BaseCookie has ambiguous unicode handling
type: behavior
versions: Python 2.5, Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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



[issue2211] Cookie.Morsel interface needs update

2008-02-29 Thread Jamie Bliss

New submission from Jamie Bliss:

Cookie.Morsel lacks in properly overloading dict methods, amongst other
things:
* .__eq__() does not take .key and .value into account
* .copy() returns a dict, not a Morsel
* .update() allows invalid attributes in, eg
Morsel().update({'eggs':'spam'}) works but Morsel()['eggs'] = 'spam' fails
* .__len__() includes unset keys (why does it set them to an empty string?)
* .__repr__() doesn't print out attributes (path, comment, etc)
* Handling of unicode is fuzzy at best: try Morsel().set(u'eggs\u00bf',
u'\u00f1', u'\00f1'.encode('utf-8'))
* Specifying the idmap and translate function in .set() seems wrong
* Setting .key doesn't check against invalid keys (eg, reserved names)
* The entire Morsel class is undocumented
* There is no way to automatically sync .value and .coded_value

--
components: Library (Lib)
messages: 63144
nosy: astronouth7303
severity: normal
status: open
title: Cookie.Morsel interface needs update
type: behavior
versions: Python 2.5, Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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



[issue1766304] improve xrange.__contains__

2008-02-29 Thread Stargaming

Stargaming added the comment:

Later on, when Greg mentions the current for/if performance asymmetry,
Guido states: 

> Fair enough. So maybe *you* can contribute a patch?

I don't read this as a rejection, but of course you're right -- this
patch is purely an optimization. As already written in my initial
comment (and discussed on the mailing list), there would be no change in
behaviour: The change from generic iterator behaviour to specific range
performance is transparent to the end-user.

I don't see how the other patches interfere with this one. Waiting until
the development of the range object itself has a stabilized and we
decided upon a member type/API seems sensible. Still, this patch would 
be valid on its own.

Now, your impulse is right: having the performance enhancement in the
bug tracker doesn't help much -- we need a resolution for this. If
someone could review the patch, tell me about the critical parts or
point me to references on how to improve it, I'd be really glad!

On the mentioned unit tests: I'm unsure how to verify this behaviour
since I expect it to affect runtime *only*.

PS. With the new tracker, wouldn't the "resource usage" type fit best?

_
Tracker <[EMAIL PROTECTED]>

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



[issue2208] Patch to doc/make.bat to allow non-standard HTML Help location

2008-02-29 Thread Georg Brandl

Georg Brandl added the comment:

Thanks, applied in r61135.

--
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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



[issue2207] Bug in Sphinx highlighting when pygments not available

2008-02-29 Thread Georg Brandl

Georg Brandl added the comment:

Thanks, fixed in r61134.

--
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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



[issue1569] Add VS CRT redist to the MSI installer

2008-02-29 Thread Martin v. Löwis

Martin v. Löwis added the comment:

Ok, I never doubted VS can do merge modules (what else if not VS could
do so?). What I'm still questioning that it is possible to do a full
Python installer as a VS setup project. I personally don't think it's
even worth the effort to try, but I might be wrong.

__
Tracker <[EMAIL PROTECTED]>

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



[issue2204] document ConfigParser behaviour when a file has same section multiple times

2008-02-29 Thread Raghuram Devarakonda

Raghuram Devarakonda added the comment:

>  Should this 'undesirable' behavior be documented? My thoughts are

Document should definitely reflect the code whether the behaviour is
desirable or not.

>  a) All the key,value pairs in the named section be retrived from entire
>  file. Just appending the dict.

Isn't this what is happening now unless I am not following you?

>  Otherwise,
>  b) An Exception can be thrown if it encounters an invalid Configfile
>  having multiple same sections which can cause problem, but I cannot
>  readily think of one such case.

I have no problem with throwing an exception in case of duplicate
sections but I don't think that can be done by default (it may break
some programs).

__
Tracker <[EMAIL PROTECTED]>

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



[issue2196] Fix hasattr's exception problems

2008-02-29 Thread Georg Brandl

Georg Brandl added the comment:

Please reformat your patch using tabs.

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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



[issue2205] os.times() returns incorrect value

2008-02-29 Thread Georg Brandl

Georg Brandl added the comment:

Isn't that tracked in #1040026?

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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



[issue2206] critical memory leak in hashlib.md5

2008-02-29 Thread Georg Brandl

Changes by Georg Brandl:


--
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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



[issue1569] Add VS CRT redist to the MSI installer

2008-02-29 Thread Jeroen Ruigrok van der Werven

Jeroen Ruigrok van der Werven added the comment:

Hi Martin,

yes, that's exactly what I am saying actually. :)

This is the resulting file I created: Python26.msi
Right now it only installs into C:\Python26 and puts python.exe, 
pythonw.exe and python26.dll there, but it is a start.

In pcbuild.sln this entry was added:

Project("{54435603-DBB4-11D2-8724-00A0C9A8B90C}") = "Python26", 
"Python26\Python26.vdproj", "{B4DFC5BC-6BEA-41B7-9A40-663F2677E506}"
EndProject

The Python26.vdproj is attached.

More work needs to be done, of course, but I merely wanted a proof of 
concept for a project file that could build a .msi and had the 
appropriate MSM integrated.

Added file: http://bugs.python.org/file9575/Python26.vdproj

__
Tracker <[EMAIL PROTECTED]>

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



[issue2210] Nested module import clutters package namespace

2008-02-29 Thread Rüdiger Kupper

New submission from Rüdiger Kupper:

When one module of a package imports another module of the same package,
the second module will not only be introduced in the namespace of the
importing module, but also in the namespace of the enclosing package.
I.e., the module will be introduced as variable
.. If the package namespace contained a
variable of this name before the import, it will be overwritten by the
new value.

For the user, import statements should act like assignments to the local
 namespace. They should never add names to an enclosing namespace. (At
least this is what all documentation and tutorials tell the user.)

Below follows a detailed example for the problem.


Say I have a package named 'pack'. Apart from the '__init__.py' file the 
directory contains two modules 'x.py' and 'y.py':

pack/
  __init__.py
  x.py
  y.py

The files have the following contents:

 __init__.py 
import x
=

 x.py ===
import y
=

 y.py ===
pass
=

I then do
 >>> import pack

This
(1) introduces variable 'x' bound to 
 in pack's namespace (expected)
(2) introduces variable 'q' bound to 
 in x's namespace (expected)
but also
(3) introduces variable 'y' bound to 
 in pack's namespace (*totally unexpected*)

The problem is so bad as to even overwrite any variable 'y' that 
might have existed in pack's namespace before the import.

I created verbose versions of the three files above to illustrate 
what happens (see below.) They do exactly the same as above, but 
print out what they do. This is the output:

-snip---
 >>> import pack
pack: Here is pack.
pack: I now assign y='hello'.
pack: My y is now: 'hello'
pack: I now 'import x' which in turn does 'import y as q'.
   x: Here is x.
   x: I now 'import y as q'.
 y: Here is y.
pack: My y is now: 
pack: Why?
snip-

I know that any import creates an entry in sys.modules. So 'pack', 
'pack.x' and 'pack.y' get created in sys.modules. That's fine.

Apart from that, an import statement should act equivalent to an 
assignment: it should introduce entries to the local namespace of the
module it appears in. The 'import y as q' appears in x.py, so it 
should add entries to x's namespace *only*.

But why is variable 'y' in pack's namespace overwritten by the 
import in x?


P.S.: These are the files that produce the verbose output. They can be
found in the tgz file attached to this issue.

 __init__.py 
print "pack: Here is pack."
print "pack: I now assign y='hello'."
y="hello"
print "pack: My y is now:", repr(y)
print "pack: I now 'import x' which in turn does 'import y as q'."
import x
print "pack: My y is now:", repr(y)
print "pack: Why?"
=

 x.py ===
print '  x: Here is x.'
print "  x: I now 'import y as q'."
import y as q
=

 y.py ===
print 'y: Here is y.'
=

--
files: pack.tgz
messages: 63135
nosy: ruediger.kupper
severity: normal
status: open
title: Nested module import clutters package namespace
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file9574/pack.tgz

__
Tracker <[EMAIL PROTECTED]>

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



[issue1152248] Enhance file.readlines by making line separator selectable

2008-02-29 Thread Nick Coghlan

Nick Coghlan added the comment:

The mail.python.org link I posted previously is broken. Here's an
updated link to the relevant c.l.p. thread:
http://mail.python.org/pipermail/python-list/2005-February/310020.html

>From my point of view, I still think it's an excellent idea and would be
happy to review a patch, but I'm unlikely to get around to implementing
it myself.

Also keep in mind that we now have the option of doing this only for the
new io module in Python 3.0 - it may be easier to do that and implement
something in pure Python rather than having to deal with the 2.x file
implementation.

(P.S. I found the double negative in Raymond's original comment a little
tricky to parse even as a native English speaker. I would also take
Skip's comment as merely discouraging adding a completely new method
rather than the original idea)

_
Tracker <[EMAIL PROTECTED]>

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



[issue2208] Patch to doc/make.bat to allow non-standard HTML Help location

2008-02-29 Thread Tim Golden

Tim Golden added the comment:

Corrected patch which replaces the @echo off at the top of the file.

Added file: http://bugs.python.org/file9573/doc-make-r61125.patch

__
Tracker <[EMAIL PROTECTED]>

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



[issue2209] mailbox module doesn't support compressed mbox

2008-02-29 Thread Jürgen A. Erhard

New submission from Jürgen A. Erhard:

(Not sure if this goes here)
The mbox class (actually, the _singlefileMailbox class) takes a path,
and not, as the old mailbox module did, an opened file object.  This
makes it hard(er) to access gzipped mbox files (mailbox.open = gzip.open
works, but is ugly).

--
components: Library (Lib)
messages: 63132
nosy: jae
severity: normal
status: open
title: mailbox module doesn't support compressed mbox
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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



[issue2208] Patch to doc/make.bat to allow non-standard HTML Help location

2008-02-29 Thread Tim Golden

New submission from Tim Golden:

The doc/make.bat file for building the docs under Windows assumes the
standard location for the HTML Help Workshop. The attached patch looks
for  an env var called HTMLHELP and uses that if it's set, falling back
to the standard location.

--
components: Documentation tools (Sphinx)
files: doc-make-r61125.patch
keywords: patch
messages: 63131
nosy: tim.golden
severity: normal
status: open
title: Patch to doc/make.bat to allow non-standard HTML Help location
versions: Python 2.6
Added file: http://bugs.python.org/file9572/doc-make-r61125.patch

__
Tracker <[EMAIL PROTECTED]>

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



[issue2207] Bug in Sphinx highlighting when pygments not available

2008-02-29 Thread Tim Golden

New submission from Tim Golden:

When pygments is not available to the sphinx build environment, the
PygmentsBridge in the highlighting.py module raises an exception in the
unhighlighted function. This function attempts to use the .dest
attribute which isn't set in the __init__ if the pygments import has failed.

The attached patch moves the .dest setting up so it is always set
regardless of the presence of pygments. I don't know if it's a complete
solution, but the help, htmlhelp and web all build.

--
components: Documentation tools (Sphinx)
files: sphinx-highlighting-r61125.patch
keywords: patch
messages: 63130
nosy: tim.golden
severity: normal
status: open
title: Bug in Sphinx highlighting when pygments not available
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9571/sphinx-highlighting-r61125.patch

__
Tracker <[EMAIL PROTECTED]>

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



[issue1657] [patch] epoll and kqueue wrappers for the select module

2008-02-29 Thread Christian Heimes

Christian Heimes added the comment:

I love to get it into the next alpha but I don't have time to today. Can
you take it to the mailing list and ask somebody to review and submit
the patch?

__
Tracker <[EMAIL PROTECTED]>

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



[issue1657] [patch] epoll and kqueue wrappers for the select module

2008-02-29 Thread Thomas Herve

Thomas Herve added the comment:

Is there a chance for this go in the first alpha? FWIW, I've tested it
with twisted kqueue and epoll reactors, and didn't get any problems.

There are still 2 typos in the patch: KQ_ADD is used 2 times in the docs
instead of KQ_EV_ADD. Everything else looks good to me.

__
Tracker <[EMAIL PROTECTED]>

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