[issue2785] alternate fast builtin sum

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

The one example given may not be convincing, other ones may be.

What is it in the submitted version which is not designed carefully or 
which may not produce the same results?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2785] alternate fast builtin sum

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

The approach of using separate accumulations is intrinsically flawed if 
you want the same result as a regular sum().  Here's a small dataset 
that shows why you can't accumulate separate sums by type:

>>> d = [1000, -
1000.0, .0001, .0001]
>>> sum(d)
2e-16
>>> d[0] + sum(d[1:])
0.0

Closing this one.  The approach is doomed and the possible benefits 
over the current approach are microscopic at best and only apply to 
unusual corner cases. 

I also prefer the current approach because it is easily extended to 
LongLongs and it is easy to show that the code is correct (at least 
with respect to producing the same result as a regular sum()).

--
resolution:  -> rejected
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

[issue2790] sys.flags is missing bytes_warning

[Ralf Schmitt]

New submission from Ralf Schmitt <[EMAIL PROTECTED]>:

sys.flags is missing bytes_warning:

Python 2.6a2+ (trunk, May  8 2008, 12:09:50) 
[GCC 4.2.3 (Debian 4.2.3-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> sys.flags
sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0,
inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0,
unicode=0)

This is only used from warnings.py currently:

~/pydev/trunk/ ack bytes_warning   
 
Lib/warnings.py
311:bytes_warning = sys.flags.bytes_warning
312:if bytes_warning > 1:
314:elif bytes_warning:

Python/sysmodule.c
1172:   {"bytes_warning", "-b"},

(I only see an attribute error in frozen programs).

The attached patch fixes it by not using the sizeof operator to compute
the size of the array.

This gives:
>>> sys.flags
sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0,
inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0,
unicode=0, bytes_warning=0)

--
files: bytes_warning.patch
keywords: patch
messages: 66411
nosy: schmir
severity: normal
status: open
title: sys.flags is missing bytes_warning
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10220/bytes_warning.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2790] sys.flags is missing bytes_warning

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

brett, I added you to the nosy list, as you seem to have committed this
in r62303 (http://hgpy.de/py/trunk/rev/ac1ae32a476c)

--
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

[issue1770190] platform.mac_ver() returning incorrect patch version

[Ronald Oussoren]

Ronald Oussoren <[EMAIL PROTECTED]> added the comment:

I've tested the patch on 10.4.10 as wel as 10.5.2 and it returns the right 
version on both platforms.

Commited as revision 62854 (trunk) and 62855 (python2.5 branch)

--
assignee: jackjansen -> ronaldoussoren
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

[issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

I've updated the release script to at least touch RELNOTES, but I'm
unsure as to what the policy is for updating the content of this file. 
I'm closing this issue but will bring it up on the mailing list.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2

[Barry A. Warsaw]

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:


--
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

[issue2791] subprocess.py leaks fd in communicate

[Joel Rosdahl]

New submission from Joel Rosdahl <[EMAIL PROTECTED]>:

The optimization in SVN rev 38556 seems to have changed
Popen.communicate's behavior when stdout is subprocess.PIPE (and maybe
for other cases as well).

See the attached file. In Python 2.4.5, all three counts are the same.
In Python 2.5.2, the middle count has increased by 1. In other words: A
file descriptor is leaked until the last reference to the Popen instance
is dropped.

--
components: Library (Lib)
files: subprocess-fd-problem.py
messages: 66415
nosy: jrosdahl
severity: normal
status: open
title: subprocess.py leaks fd in communicate
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file10221/subprocess-fd-problem.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue1346238] A constant folding optimization pass for the AST

[Jeremy Hylton]

Changes by Jeremy Hylton <[EMAIL PROTECTED]>:


--
nosy: +jhylton

_
Tracker <[EMAIL PROTECTED]>

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

[issue2650] re.escape should not escape underscore

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

Lorenz's patch uses a set, not a list for special characters.  Set 
lookup is as fast as dict lookup, but a set takes less memory because it 
does not have to store dummy values.  More importantly, use of frozenset 
instead of dict makes the code clearer.  On the other hand, I would 
simply use a string.  For a dozen entries, hash lookup does not buy you 
much.

Another nit: why use "\\%c" % (c) instead of obvious "\\" + c?

Finally, you can eliminate use of index and a temporary list altogether 
by using a generator expression:

''.join(("\\" + c if c in _special else '\\000' if c == "\000" else c),
for c in pattern)

--
nosy: +belopolsky

__
Tracker <[EMAIL PROTECTED]>

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

[issue2523] binary buffered reading is quadratic

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Some code relies on -1 being usable as the default value for read()
(instead of None), this new patch conforms to this expectation. It fixes
some failures in test_mailbox.

Added file: http://bugs.python.org/file10222/binaryio2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2650] re.escape should not escape underscore

[Russ Cox]

Russ Cox <[EMAIL PROTECTED]> added the comment:

> Lorenz's patch uses a set, not a list for special characters.  Set 
> lookup is as fast as dict lookup, but a set takes less memory because it 
> does not have to store dummy values.  More importantly, use of frozenset 
> instead of dict makes the code clearer.  On the other hand, I would 
> simply use a string.  For a dozen entries, hash lookup does not buy you 
> much.
> 
> Another nit: why use "\\%c" % (c) instead of obvious "\\" + c?
> 
> Finally, you can eliminate use of index and a temporary list altogether 
> by using a generator expression:
> 
> ''.join(("\\" + c if c in _special else '\\000' if c == "\000" else c),
> for c in pattern)

The title of this issue (#2650) is "re.escape should not escape underscore",
not "re.escape is too slow and too easy to read".

If you have an actual, measured performance problem with re.escape,
please open a new issue with numbers to back it up. 
That's not what this one is about.

Thanks.
Russ

__
Tracker <[EMAIL PROTECTED]>

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

[issue2650] re.escape should not escape underscore

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Thu, May 8, 2008 at 10:36 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
..
>  The title of this issue (#2650) is "re.escape should not escape underscore",
>  not "re.escape is too slow and too easy to read".
>

Neither does the title say "re.escape should only escape
.^$*+?{}[]\|()".  I reviewed the patch rather than its conformance
with the title.  (BTW, the patch does not update documentation in
Doc/library/re.rst.)

>  If you have an actual, measured performance problem with re.escape,
>  please open a new issue with numbers to back it up.
>  That's not what this one is about.

You don't need to get so defensive.  I did not raise a performance
problem, I was simply responding to Rafael's "AFAIK the lookup on
dictionaries is faster than on lists" comment.  I did not say that you
*should* rewrite your patch the way I suggested, only that you *can*
use new language features to simplify the code.

In any case, I am -0 on the patch.  The current documentation says:

"""
escape(string)

   Return *string* with all non-alphanumerics backslashed; this is useful if you
   want to match an arbitrary literal string that may have regular expression
   metacharacters in it.

"""

and the current implementation serves the intended use case well.  I
did not see a compelling use case presented for the change.  On the
downside, since there is no mechanism to assure that _special indeed
contains all re metacharacters, it may present a maintenance problem
if additional metacharacters are added in the future.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2650] re.escape should not escape underscore

[Russ Cox]

Russ Cox <[EMAIL PROTECTED]> added the comment:

> You don't need to get so defensive.  I did not raise a performance
> problem, I was simply responding to Rafael's "AFAIK the lookup on
> dictionaries is faster than on lists" comment.  I did not say that you
> *should* rewrite your patch the way I suggested, only that you *can*
> use new language features to simplify the code.

I was responding to the entire thread more than your mail.
I'm frustrated because the only substantial discussion has
focused on details of how to implement set lookup the fastest
in a function that likely doesn't matter for speed.

> In any case, I am -0 on the patch.  The current documentation says:

Now these are the kinds of comments I was hoping for.
Thank you.

>Return *string* with all non-alphanumerics backslashed; this is useful if 
> you
>want to match an arbitrary literal string that may have regular expression
>metacharacters in it.

Sure; the documentation is wrong too.

> I did not see a compelling use case presented for the change.  

The usual convention in regular expressions is that escaping
a word character means you intend a special meaning, and
underscore is a word character.  Even though the current re
module does accept \_ as synonymous with _ (just as it accepts
\q as synonymous with q), it is no more correct to escape _ than
to escape q.

I think it is fine to escape all non-word characters, but someone
else suggested that it would be easier when moving to larger
character sets to escape just the special ones.  I'm happy with
either version.

My argument is only that Python should behave the same in 
this respect as other systems that use substantially the same
regular expressions.

> since there is no mechanism to assure that _special indeed
> contains all re metacharacters, it may present a maintenance problem
> if additional metacharacters are added in the future.

The test suite will catch these easily, since it checks that 
re.escape(c) matches c for all characters c.  But again, I'm happy
with escaping all ASCII non-word characters.

Russ

__
Tracker <[EMAIL PROTECTED]>

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

[issue2650] re.escape should not escape underscore

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Thu, May 8, 2008 at 11:45 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
..
>  My argument is only that Python should behave the same in
>  this respect as other systems that use substantially the same
>  regular expressions.
>

This is not enough to justify the change in my view.  After all, "A
Foolish Consistency is the Hobgoblin of Little Minds"
.

I don't know if there is much code out there that relies on the
current behavior, but technically speaking, this is an incompatible
change.  A backward compatible way to add your desired functionality
would be to add the "escape_special" function, but not every useful
3-line function belongs to stdlib.

This said, I would prefer simply adding '_' to _alphanum over _special
approach, but still -1 on the whole idea.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2650] re.escape should not escape underscore

[Russ Cox]

Russ Cox <[EMAIL PROTECTED]> added the comment:

On Thu, May 8, 2008 at 12:12 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
>
> Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
>
> On Thu, May 8, 2008 at 11:45 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
> ..
>>  My argument is only that Python should behave the same in
>>  this respect as other systems that use substantially the same
>>  regular expressions.
>>
>
> This is not enough to justify the change in my view.  After all, "A
> Foolish Consistency is the Hobgoblin of Little Minds"
> .
>
> I don't know if there is much code out there that relies on the
> current behavior, but technically speaking, this is an incompatible
> change.  A backward compatible way to add your desired functionality
> would be to add the "escape_special" function, but not every useful
> 3-line function belongs to stdlib.

In my mind, arguing that re.escape can't possibly be changed
due to imagined backward incompatibilities is the foolish consistency.

> This said, I would prefer simply adding '_' to _alphanum over _special
> approach, but still -1 on the whole idea.

I don't use Python enough to care one way or the other.
I noticed a bug, I reported it.  Y'all are welcome to do
as you see fit.

Russ

__
Tracker <[EMAIL PROTECTED]>

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

[issue2650] re.escape should not escape underscore

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

I haven't assessed the patch, but wouldn't mind to see it applied to 
an alpha release or to 3.0; +0 from me.  Given that the next 2.6 release
is planned to be a beta, though, the release manager would have to rule.

Note that I don't think this change is actually backwards-incompatible
and is actually fairly low-risk.  It does change what re.escape will
return, but the common use-case is escaping some user- or data-supplied
string so that it can be passed to re.compile()without triggering a
syntax error or very long loop.  In that use-case, whether it returns _
or \_ is immaterial; the result is the same.  Doing a Google code search
for re.escape confirms that this is the general usage.

Interestingly, SCons defines its own re_escape, with a comment saying '#
re.escape escapes too much'.  But their function doesn't escape \ or $
at all, so I don't understand why they bothered.

On the other hand, if this patch doesn't affect the usage of the
function, why bother?  Matching Perl or other systems probably won't
improve interoperability very much, so the release manager might decide
to leave well enough alone.

--
nosy: +akuchling

__
Tracker <[EMAIL PROTECTED]>

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

[issue2790] sys.flags is missing bytes_warning

[Christian Heimes]

Changes by Christian Heimes <[EMAIL PROTECTED]>:


--
assignee:  -> christian.heimes
nosy: +christian.heimes
priority:  -> high

__
Tracker <[EMAIL PROTECTED]>

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

[issue2630] repr() should not escape non-ASCII characters

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

On 2008-05-06 19:10, Guido van Rossum wrote:
> Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> 
> On Tue, May 6, 2008 at 1:26 AM, Marc-Andre Lemburg wrote:
>>  So you've limited the codec design to just doing Unicode<->bytes
>>  conversions ?
> 
> Yes. This was quite a conscious decision that was not taken lightly,
> with lots of community input, quite a while ago.
> 
>>  The original codec design was to have the codec decide which
>>  types to take on input and to generate on output, e.g. to
>>  escape characters in Unicode (converting Unicode to Unicode),
>>  work on compressed 8-bit strings (converting 8-bit strings to
>>  8-bit strings), etc.
> 
> Unfortunately this design made it hard to reason about the correctness
> of code, since (especially in Py3k, where bytes and str are more
> different than str and unicode were in 2.x) it's hard to write code
> that uses .encode() or .decode() unless it knows which codec is being
> used.
> 
> IOW, when translated to 3.0, the design violates the general design
> principle that the *type* of a function's or method's return value
> should not depend on the *value* of one of the arguments.

I understand where this concept originates and usual apply this
rule to software design as well, however, in the particular case
of codecs, the codec registry and its helper functions are merely
interfaces to code that is defined elsewhere.

In comparison, the approach is very much like getattr() - you know
what the attribute is called, but know nothing about its type
until you receive it from the function.

The reason codecs where designed like this was to be able to
easily stack them. For this to work, only the interfaces need
to be defined, without restricting the codecs too much in terms
of which types may be used.

I'd suggest to lift the type restrictions from the general
codecs.c access APIs (PyCodec_*), since they don't really belong
there and instead only impose the limitation on PyUnicode and
PyString methods .encode() and .decode().

If you then also allow those methods to return *both*
PyUnicode and PyString, you'd still have strong typing
(only 1 of two possible types is allowed) and stacking
streams or having codecs that work on PyUnicode->PyUnicode
or PyString->PyString would still be accessible via
.encode()/.decode().

>>  >>  I think you have to ask another question: Is repr() allowed to
>>  >>  return a string (instead of Unicode) in Py3k ?
>>  >
>>  > In Py3k, "strings" *are* unicode. The str data type is Unicode.
>>
>>  With "strings" I always refer to 8-bit strings, ie. 8-bit data that
>>  is encoded in some encoding.
> 
> You will have to change this habit or you will thoroughly confuse both
> users and developers of 3.0. "String" refers to the built-in "str"
> type which in Py3k is PyUnicode. For the PyString type we use the
> built-in type "bytes".

Well, I'm confused by the P3k use of terms (esp. because the
C type names don't match the Python ones), which is why I'm
talking about 8-bit strings and Unicode.

Perhaps it's better to use PyString and PyUnicode.

>>  > If you're asking about repr() possibly returning a bytes instance,
>>  > definitely not.
>>  >
>>  >>  If not, then unicode_repr() will have to check the return value of
>>  >>  the codec and convert it back to Unicode as necessary.
>>  >
>>  > What codec?
>>
>>  The idea is to have a codec which takes the Unicode object and
>>  converts it to its repr()-value.
>>
>>  Now, since you apparently cannot
>>  go the direct way anymore (ie. have the codec encode Unicode to
>>  Unicode), you'd have to first use a codec which converts the Unicode
>>  object to its repr()-value represented as bytes object and then
>>  convert the bytes object back to Unicode in unicode_repr().
>>
>>  With the original design, this extra step wouldn't have been
>>  necessary.
> 
> Why does everything have to be a codec?

It doesn't. It's just that codecs are so easy to add, change
and adjust that reusing the existing code is more attractive
than reinventing the wheel every time you need to make
a conversion from one text form to another adjustable in
some way.

In the case addresses by this ticket, I see the usefulness
of having native language being written to the console using
native glyphs, but there are so many drawbacks to this (see the
discussion on the ticket and the mailing list), that
I think there needs to be a way to adjust the mechanism
or at least be able to revert to the existing repr() output.

Furthermore, a codec implementation of what Atsuo has in mind
would also be useful in other contexts, e.g. where you want
to write PyUnicode to a stream without introducing line breaks.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/optio

[issue2630] repr() should not escape non-ASCII characters

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I'd be happy to have a separate more relaxed API for stackable codecs,
however, the API should not be overloaded on the .encode() and .decode()
methods on str and bytes objects.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2778] set_swap_bodies is unsafe

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Added documentation in r62873.  Leaving the code as-is.

--
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

[issue2748] ceil(), floor() and round() broken in Decimal

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
assignee: rhettinger -> marketdickinson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2778] set_swap_bodies is unsafe

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

I've been unable to find any discussion on this feature.  If anything, I
think when PEP 218 was discussed and accepted (and PEP 351 rejected),
the assumption was it didn't exist.  Adding it now should be regarded as
a new feature and discussed on python-dev.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2778] set_swap_bodies is unsafe

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

Nevermind that the current implementation *is* broken, even if you
consider fixing it to be a low priority.  Closing the report with a doc
tweak isn't right.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2778] set_swap_bodies is unsafe

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Sorry, you don't like the search with autopromotion feature. It has 
been around since sets were first coded in C.  It is a natural 
extension/consequence of the idea that frozenset('abc')==set('abc').

__
Tracker <[EMAIL PROTECTED]>

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

[issue2778] set_swap_bodies is unsafe

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

So why doesn't set() in {} work?  Why was PEP 351 rejected when it would
do this properly?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2790] sys.flags is missing bytes_warning

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Ralf, can you do a ``make clean`` and then try again? I had this happen to 
me with an old checkout until I did that and then everything worked fine.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2651] Strings passed to KeyError do not round trip

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Wouldn't it be nice to also store the offending key as a "key" attribute?
Writing key_error.key is a lot intuitive than key_error.args[0] (or is
it key_error.args[1] ? I've already forgotten :-)).

--
nosy: +pitrou

__
Tracker <[EMAIL PROTECTED]>

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

[issue2786] Names in traceback should have class names, if they're methods

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

This is similar to issue2516.

--
nosy: +belopolsky

__
Tracker <[EMAIL PROTECTED]>

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

[issue2792] alternate fast builtin sum, rev'd

[Jean Brouwers]

New submission from Jean Brouwers <[EMAIL PROTECTED]>:

Here is one more, final attempt to improve fast summation, somewhat.

This version inspects the type of both the sum and the first item and 
adds all ints and floats without any PyNumber_Add() call and in order.

Also, the results for this test case are compatible:

>>> d = [1000, -1000.0, .0001, 
.0001]
>>> sum(d)
2e-16
>>> d[0] + sum(d[1:])
0.0

/Jean Brouwers

--
components: Interpreter Core
files: bltinmodule3.c.diff
keywords: patch
messages: 66434
nosy: MrJean1
severity: normal
status: open
title: alternate fast builtin sum, rev'd
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file10223/bltinmodule3.c.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2790] sys.flags is missing bytes_warning

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

sure, I even removed the whole source tree:
~/pydev/trunk/ ./python  
[EMAIL PROTECTED] ok
Python 2.6a3+ (trunk, May  8 2008, 21:52:39) 
[GCC 4.2.3 (Debian 4.2.3-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> sys.flags
sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0,
inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0,
unicode=0)

You can count the entries manually if you don't believe. The given count
is off by one.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2793] Dictionary fails to index when adding list when in a deeply nested loop

[James Nadir]

New submission from James Nadir <[EMAIL PROTECTED]>:

Python fails to correctly add 'lists' into a 'dictionary' in nested 
loop. The attached py file has two examples; the first is the failing 
example, the seond is the passing example. 

This might be a known issue. If so, please accept my apologies, I 
couldn't find it. Or it could be operator error. Again, my apolgies if 
it is.

--
files: play parser.py
messages: 66436
nosy: jreadon
severity: normal
status: open
title: Dictionary fails to index when adding list when in a deeply nested loop
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10224/play parser.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2794] Figure directive not handled for latex writing in Sphinx

[Ali Afshar]

New submission from Ali Afshar <[EMAIL PROTECTED]>:

.. figure:: directive is not handled when writing to latex, and this
directive seems the only way to have a captioned image in rst.

I have added a patch that simply handles the figure, and captions.

Note that figures have an additional component of "legends" but I can't
seem to work out what these are.

--
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: latex-figure.diff
keywords: patch
messages: 66437
nosy: aafshar, georg.brandl
severity: normal
status: open
title: Figure directive not handled for latex writing in Sphinx
versions: Python 2.5
Added file: http://bugs.python.org/file10225/latex-figure.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2790] sys.flags is missing bytes_warning

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Fixed in r62896.

--
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

[issue2780] Python 3.0a4 crashes on script in a path with non-ASCII characters (Windows)

[Tim Pietzcker]

Tim Pietzcker <[EMAIL PROTECTED]> added the comment:

I should perhaps add that this happened on a German Windows XP Pro SP2
installation.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2790] sys.flags is missing bytes_warning

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

why not use sizeof? you'll probably run into this again..

__
Tracker <[EMAIL PROTECTED]>

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

[issue1342] Crash on Windows if Python runs from a directory with umlauts

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

I'm increasing the severity of the bug. It's a still a major show
stopper for non-English Windows users. For example see #2780

--
priority: normal -> release blocker

__
Tracker <[EMAIL PROTECTED]>

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

[issue2793] Dictionary fails to index when adding list when in a deeply nested loop

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

No, there is no problem with Python here.

In your "failing" example, you insert the same object ("new_record")
into the dictionary. Right, you modify its content, but it is still the
same list object; All values in the dictionary are the same object, and
are identical... A list object is said "mutable": if you modify it, you
modify all other references to the list.
A solution is to *copy* the list before adding it into the dictionary,
so that the initial list can be modified without impacting the previous
entries.

By the way, there are at least two more inconsistencies in your example:

1)  record!=''or'\n' 
does not mean what I think you intended. Python reads this as 
 (record != '')or ('\n')
Since the right-hand side is a non-empty string, python will evaluate
the condition as True value, always. 
I think you meant something like:
record != '' or record != '\n' 
which can also be written:
record not in ('', '\n')

2)   new_record !='\n'
always succeed, since new_record is a list...

--
nosy: +amaury.forgeotdarc
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

[issue2790] sys.flags is missing bytes_warning

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

btw, I guess that sentinel entry in that array could also be removed?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2780] Python 3.0a4 crashes on script in a path with non-ASCII characters (Windows)

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Das Problem ist bekannt. Trotzdem danke!

--
nosy: +christian.heimes
resolution:  -> duplicate
status: open -> closed
superseder:  -> Crash on Windows if Python runs from a directory with umlauts

__
Tracker <[EMAIL PROTECTED]>

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

[issue2790] sys.flags is missing bytes_warning

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

I didn't use sizeof because I didn't think of it; the solution to just 
change the numbers was right in front of me and I am swamped with other 
work so I went with what I knew would work.

As for removing the array, perhaps, but I don't have time to try that out.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2448] namedtuple breaks refleak tests

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

The tests are passing again.

--
resolution:  -> out of date
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

[issue2790] sys.flags is missing bytes_warning

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

ok brett, I see in IRC you're doing lot's of commits currently. sorry
for bothering you. I'll maybe try myself, it's a minor issue anyway...

__
Tracker <[EMAIL PROTECTED]>

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

[issue1799] PEP 370

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

The PEP370 has been accepted and the patch has been applied.

--
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

[issue2792] alternate fast builtin sum, rev'd

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Attached is a slightly better version, making the float loop cleaner.  Use 
this one and disregard the earlier one, bltinmodule3.c.diff.

/Jean Brouwers

Added file: http://bugs.python.org/file10226/bltinmodule4.c.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2795] rename "Caveat" to "Warning"

[Benjamin Peterson]

New submission from Benjamin Peterson <[EMAIL PROTECTED]>:

The reST directive "warning" gives a orange box with "Caveat" in bold
letters. I think this makes assumptions about the contents of the box
(Warning is broader than caveat). Could it be changed to just "Warning?"

--
assignee: georg.brandl
components: Documentation
messages: 66450
nosy: benjamin.peterson, georg.brandl
priority: low
severity: normal
status: open
title: rename "Caveat" to "Warning"
type: feature request

__
Tracker <[EMAIL PROTECTED]>

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

[issue2792] alternate fast builtin sum, rev'd

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
assignee:  -> rhettinger
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue2792] alternate fast builtin sum, rev'd

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Sorry, I really do not want to change the existing code.  It's clear, 
does exactly what it's supposed to do, is easily checked for 
correctness, been seen and exercised in the alphas for a good while.  
It gives a good tenfold speed-up (YMMV depending on machine and 
compiler).  Also, it is setup in a way that will make it easy to add 
special handling of LongLongs.  

I spend several days on the existing code to make sure that the 
conversions and accumulations exactly matches what sum() was already 
doing behind the scenes.  Then, a good deal of time was spent making 
before/after timings of various cases and comparing the result to psyco 
generated code. I'm reluctant to throw-away those efforts and then 
invest the same time with another patch that cannot produce any 
signficant speedups.

The submitted code is longer and is harder for me to verify that it is 
correct -- I've spent hours with it already and am not confident about 
the code.  ISTM, that the code is twisting itself in knots just to 
avoid a single call to PyNumber_Add in an uncommon case.  I find the 
coding style uncomfortable and do not readily see how to extend it to 
the LongLong case.

The existing code follows are series of required steps to assume a type 
and continuously verify that assumption.  Those steps which comprise 
the bulk of the work are mandatory.  So, all you can do with alternate 
patches is rearrange the loops and in-inlining for a microscopic speed-
up at best.  There is no new approach here that is worth the time spent 
reviewing and re-reviewing patches.  Unless you can get meaningful 
speed-ups in the common cases, please stop re-arranging this code.

Also, the submission should have been accompanied by a full set of 
before/after timings across a variety of use cases including short 
lists, summing all ints, summing all floats, summing a random mix of 
ints and floats, all longs, etc.  And, it would have been nice to have 
a conceptual statement of what the code purports to do differently -- 
what you think makes it better.

Sorry.  I know you're having fun with this.  But micro-tweaks at this 
point are a total waste of time.  It takes too much effort to verify 
correctness, run all the timings, and create code that is 
maintainable/extendable. Try to be content with the tenfold speedup 
we've already gotten.

A better use of time would be to scan the code base for other places 
that would benefit from the pattern of assuming a type, verifying the 
assumption, running type specific code, and falling back if the 
assumption fails.  Focus the effort of common use cases (like for sum() 
where the effort focused on all ints or all floats and a mixed-case.

--
resolution:  -> rejected
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

[issue2795] rename "Caveat" to "Warning"

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

+1

--
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue2784] fast builtin sum may leak

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
priority:  -> high

__
Tracker <[EMAIL PROTECTED]>

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

[issue2795] rename "Caveat" to "Warning"

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Fixed in r62926.

--
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

[issue2788] ignore file for Mercurial

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Added in r62927.

--
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

[issue2781] Tiny patch to _winreg docs

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Thanks, fixed in r62928.

--
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

[issue2487] ldexp(x,n) misbehaves when abs(n) is large

[Fredrik Johansson]

Fredrik Johansson <[EMAIL PROTECTED]> added the comment:

I'm not qualified to comment on the implementation. The test cases all
look right.

__
Tracker <[EMAIL PROTECTED]>

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