Georg Brandl <[EMAIL PROTECTED]> added the comment:
Winfried, can you try again with the newest trunk?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Georg Brandl <[EMAIL PROTECTED]> added the comment:
But there is a "path.exists()" condition around the rmtree, isn't there?
___
Python tracker <[EMAIL PROTECTED]>
<ht
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Great! Thanks for the patience.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
The only way to get this right for arbitrary tables is to hand-select
the column widths with a "tabularcolumns" directive.
I'll keep this issue open and optimize these columns step by step.
--
Georg Brandl <[EMAIL PROTECTED]> added the comment:
The advantage of HTML here is that the browser dynamically adjusts the
column widths to prevent things like in your screenshot from happening.
LaTeX does no such thing. If you tell it that the column width 20%, the
column will not be en
Georg Brandl <[EMAIL PROTECTED]> added the comment:
I do not think the partial object should have the original function's
__name__ or __doc__. It is after all not that function, but a callable
that calls it. (This is different from e.g. a decorated function -- the
decorator
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Looks fine.
As a bonus, you can find out why "unicode_literals" doesn't work when
used in an exec'd string -- this is why I didn't upload my fix yet.
--
nosy: +georg.
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4219>
___
___
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Since it is not defined which bytes are used as digits for bases > 36,
\x00 is not a "valid byte".
In any case, the problem here is that the base check is done after the
"no NULL" check. Perhaps the error should ex
Georg Brandl <[EMAIL PROTECTED]> added the comment:
If I understand English correctly, I don't see an ambiguity.
Probably the poster(s) on c.l.p didn't look properly and read something
like "equivalent to key in d, but the latter is deprecated".
The d/dict inc
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Forgive me for playing stupid here, but I want to understand English
better. I would fully understand the confusion had the sentence been
"dict.has_key(key) is equivalent to key in d, but it is deprecated."
Terry'
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, committed as changeset 693fa9bb3b39.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Moved to http://www.bitbucket.org/birkenfeld/sphinx/issue/31.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Moved to http://www.bitbucket.org/birkenfeld/sphinx/issue/32.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Moved to http://www.bitbucket.org/birkenfeld/sphinx/issue/33.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, fixed in r67101.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
This is already tracked in
http://www.bitbucket.org/birkenfeld/sphinx/issue/26/sphinxsty-incompatible-with-texlive-sphinx.
--
resolution: -> duplicate
status: open -> closed
___
Py
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Now tracked in
http://www.bitbucket.org/birkenfeld/sphinx/issue/6/fix-html-generation-for-tocs.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <[EMAIL PR
Georg Brandl <[EMAIL PROTECTED]> added the comment:
The issue is not as "easy" as it seems (or at least that's what I believe).
Barry, if you install the xetex package, the build should run fine.
___
Python tracker <[EMAIL PROTECTED]&
Georg Brandl <[EMAIL PROTECTED]> added the comment:
> In other words, the various *Tex packages cannot agree on a common syntax?
No, syntax has nothing to do with it. It was a mistake of some sort on
my part. It depends on whether the "ifxetex" latex package is present,
b
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, fixed in r67117.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, applied in r67118.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
I agree -- fixed in r67119.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
This is fixed in the new docs, see
<http://docs.python.org/library/stdtypes#str.split>.
--
resolution: -> out of date
status: open -> closed
___
Python tracker <[EM
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Committed in r67123. Thanks!
--
nosy: +georg.brandl
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Actually, that the build doesn't work is almost OK, because that seealso
directive was invalid markup syntax (until very recently) :)
Anyway, should be fixed now after a "make update".
--
resolution: -> fixe
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Should be fixed in Sphinx rev 735:a4019921bdf4.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, fixed in r67160.
--
nosy: +georg.brandl
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
It doesn't directly translate. I'm going to switch the Python docs'
build setup to checkout from Hg soon.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Georg Brandl <[EMAIL PROTECTED]> added the comment:
FYI: This is now fixed in tip.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4189>
___
_
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Closing; changing this will at least need a python-dev discussion, and
thorough motivation.
--
nosy: +georg.brandl
resolution: -> wont fix
status: open -> closed
___
Python tra
Georg Brandl <[EMAIL PROTECTED]> added the comment:
What good is a comparison with InstanceType for? If you want to check
whether it's an instance of a custom class, you'll have to check for
instances of new-style classes anyway. If you want to check for UserList
instances
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
assignee: georg.brandl -> loewis
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, fixed in r67224.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, applied in r67227.
--
nosy: +georg.brandl
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
I repeat, what is this "easy" condition good for?
___
Python tracker <[EMAIL PROTECTED]>
<http://
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
assignee: georg.brandl -> zseil
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Georg Brandl <[EMAIL PROTECTED]> added the comment:
I vote yes.
--
nosy: +georg.brandl
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67328.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67329.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67330.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Added __cmp__ issue in r67331.
--
nosy: +georg.brandl
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, fixed in r67334.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed applyAsync and missing ] in r67335.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
assignee: georg.brandl -> jnoller
nosy: +jnoller
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks for noting this! The most basic changes had been done, but I had
to revise some sections for changes. Done in r67338.
--
resolution: -> fixed
status: open -> closed
___
Py
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Okay, I applied your latest patch as changeset 970452b02e2e. Thanks!
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67355.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67359, thanks!
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
assignee: -> georg.brandl
components: +Documentation
nosy: +georg.brandl
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Are you sure you run the latest 2to3? I ran it over docutils last night,
and while the version distributed with 2.6 failed with the same
exception, the current 2to3 from the sandbox worked.
--
nosy: +georg.
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Should be fixed in r67368.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Please submit Sphinx bugs in its own tracker:
http://bitbucket.org/birkenfeld/sphinx/issues
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PR
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Please submit Sphinx bugs in its own tracker:
http://bitbucket.org/birkenfeld/sphinx/issues
(Yes, I know there was still a Sphinx component -- I've removed that now.)
--
resolution: -> invalid
status:
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
assignee: georg.brandl -> loewis
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Georg Brandl <[EMAIL PROTECTED]> added the comment:
It is "valid" Python 3 and the lack of an effect on the local is correct.
>From Python 3 on, "exec" is a function and therefore lacks the special
magic properties it had in Python 2 that made it possible execut
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Like Amaury said, I think this is fixed.
--
resolution: -> fixed
status: open -> pending
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67526.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67525.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, applied as r67527.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Yes, this was a temporary workaround for another issue. 3.0 and 3.1 docs
are now properly separated and linked to.
--
resolution: -> fixed
status: open -> closed
___
Python tra
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed now, thanks.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
This appears to be fixed in SVN.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
This appears to be fixed in SVN.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67529.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, committed in r67551.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Re-added os.extsep to the os module in r67552.
--
nosy: +georg.brandl
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67553.
--
nosy: +georg.brandl
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Should be fixed in r67554.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Georg Brandl <[EMAIL PROTECTED]>:
Applied in r67555.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67556. If a Windows guy can give me more specific directions
where to find the equivalent options, I'll put it in.
--
resolution: -> fixed
status: open -> closed
_
Georg Brandl <[EMAIL PROTECTED]> added the comment:
It's not documented for any immutable type. This should be fixed.
--
title: datetime not subclassable in the usual way -> document immutable type
subclassing via __new__
___
Python t
Georg Brandl <[EMAIL PROTECTED]> added the comment:
This is tracked in Sphinx' tracker at
http://www.bitbucket.org/birkenfeld/sphinx/issue/10/html-section-numbering.
--
resolution: -> duplicate
status: open -> closed
___
Pytho
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67572. I won't backport this.
--
nosy: +georg.brandl
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Added link in r67574.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4441>
___
__
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Ping!
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1675334>
___
___
Python-bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
I see the same as Antoine, this is fixed in 2.6.
--
nosy: +georg.brandl
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Georg Brandl <[EMAIL PROTECTED]> added the comment:
All open items in this issue seem to be addressed
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Georg Brandl <[EMAIL PROTECTED]> added the comment:
I guess this is now an item for Python 2.7.
--
nosy: +georg.brandl
title: Update to latest ElementTree in Python 2.6 -> Update to latest
ElementTree in Python 2.7
versions: +Python 2.7 -P
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Georg Brandl <[EMAIL PROTECTED]> added the comment:
The docs already say
"Because the C signal handler always returns, it makes little sense to
catch synchronous errors like :const:`SIGFPE` or :const:`SIGSEGV`."
Should this still be reworded or promoted to a warning?
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1223>
___
___
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1366>
___
___
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Georg Brandl <[EMAIL PROTECTED]>:
--
resolution: -> duplicate
status: open -> closed
superseder: -> regrtest.py -R not working
___
Python tracker <[EMAIL PROTECTED]>
<http://b
Georg Brandl <[EMAIL PROTECTED]> added the comment:
The docstrings are now fixed too.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67575, will be ported to all branches.
--
nosy: +georg.brandl
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Why is the overflow handling changed at all?
--
nosy: +georg.brandl
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67576, will be ported to all branches.
--
nosy: +georg.brandl
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
This is already fixed in SVN and will be upated with the next rebuild of
the docs.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Isn't what you refer to covered by this paragraph and the following
example: "In addition to bypassing any instance attributes in the
interest of correctness, implicit special method lookup may also bypass
the __getattribute__(
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, fixed in r67578.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Thanks, fixed in r67578.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Georg Brandl <[EMAIL PROTECTED]> added the comment:
I've changed "may bypass" to "generally bypasses". It doesn't happen for
all methods, but that's an implementation detail.
I've also added a glossary entry "special method" in r67579.
Georg Brandl <[EMAIL PROTECTED]> added the comment:
In the 2.6 and 3.0 docs, decorators do have an index entry, see
http://docs.python.org/genindex-D.html.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PR
Georg Brandl <[EMAIL PROTECTED]> added the comment:
Fixed in r67580.
If we want to start using things like :raises:, it will have to be in
some coordinated fashion so that it doesn't occur in isolated places.
--
resolution: -> fixed
status:
Georg Brandl <[EMAIL PROTECTED]> added the comment:
This is not a bug. By default, options in optparse take an argument --
therefore, the -y is taken as the argument to the -p option.
Use e.g. add_option(..., action='store_true') to specify an option that
doesn
2501 - 2600 of 5257 matches
Mail list logo