[issue4825] TypeError with complex.real() and complex.imag()

[Georg Brandl]

Changes by Georg Brandl :


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

[issue4811] invalid reST markup in several documents

[Gabriel Genellina]

Changes by Gabriel Genellina :


Added file: http://bugs.python.org/file12579/suspicious.rar

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Paolo 'Blaisorblade' Giarrusso]

Paolo 'Blaisorblade' Giarrusso  added the comment:

@Alexandre:
> > So, can you try dropping the switch altogether, using always computed
> > goto and seeing how does the resulting code get compiled?

> Removing the switch won't be possible unless we change the semantic
> EXTENDED_ARG. In addition, I doubt the improvement, if any, would worth
> the increased complexity.
OK, it's time that I post code to experiment with that - there is no
need to break EXTENDED_ARG. And the point is to fight miscompilations.

> Do you actually mean the time spent interpreting bytecodes compared to
the time spent in the other parts of Python? If so, your figures are
wrong for CPython on x86-64. It is about 50% just like on x86 (when
running pybench). With the patch, this drops to 35% on x86-64 and to 45%
on x86.

More or less, I mean that, but I was making an example, and I made up
reasonable figures.
70%, or even more, just for _dispatch_ (i.e. just for the mispredicted
indirect jump), is valid for real-world Smalltalk interpreters for
instance, or for the ones in "The Structure and Performance of Efficient
Interpreters".
But, when you say "intepreting opcodes", I do not know which part you
refer to, if just the computed goto or for the whole code in the
interpreter function.

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Paolo 'Blaisorblade' Giarrusso]

Paolo 'Blaisorblade' Giarrusso  added the comment:

@Skip: if one decides to generate binary code, there is no need to use
switches. Inline threading (also known as "code copying" in some
research papers) is what you are probably looking for:

http://blog.mozilla.com/dmandelin/2008/08/27/inline-threading-tracemonkey-etc/

For references and background on threading techniques mentioned there, see:

http://en.wikipedia.org/wiki/Threaded_code
http://www.complang.tuwien.ac.at/forth/threaded-code.html

___
Python tracker 

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

[issue4815] idle 3.1a1 utf8

[Pavel Kosina]

Pavel Kosina  added the comment:

Martin v. Löwis napsal(a), dne 4.1.2009 14:39:
> Why that? This file is already encoded in utf-8 just fine. It is,
> simultaneously, also encoded in ASCII, cp1250, cp1252, and nearly
> any other encoding in use (as long as it is ASCII-based).
>   

Well I am not much experienced but this file is not real utf8. It is 
encoded in ascii, cp1250, cp1252, and many other but not in utf8. utf8 
has a special flag, special bytes inside  - as a special mark for 
editors. That is what this file doesnt have. Even after making change in 
it in IDLE, it does not became real utf8. I always check it in another 
editor, that can work with encoding very well - PSPad.

___
Python tracker 

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

[issue4832] idle filename extension

[Pavel Kosina]

New submission from Pavel Kosina :

There should not be necessity to write filename *with extension* at the
saving dialog. It should be enough, at least on Windows, to put there
just "hello" and get "hello.py". It is really complication especially
for beginners. If they, as they are used to from another programs, put
there just "hello", it is saved without extension ".py" what have 2
result: they cannot see any icons at that file and they are not able to
run in, cause python.exe is bind with ".py".

Hoping its not duplicate I haven't found anything like this here.

--
components: IDLE
messages: 79062
nosy: geon
severity: normal
status: open
title: idle filename extension
type: behavior
versions: Python 2.5, 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

[issue4831] exec() behavior - revisited

[David M. Beazley]

David M. Beazley  added the comment:

One further followup just to make sure I'm clear.

Is it always safe to pass the result of locals() into exec and extract 
the result as shown in my example?  

Since I'm writing about this in a book, I just want to make absolutely 
certain I know what's going on and that I don't tell people something 
that's completely bogus.

Thanks!

___
Python tracker 

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

[issue4506] 3.0 make test failures on Solaris 10

[Mark Dickinson]

Mark Dickinson  added the comment:

autoconf checks for isinf and isnan fixed in r68299.
I also added a check for isfinite, which should really be used in 
preference to finite:  isfinite is standard in C99, while finite doesn't 
seem to be part of any standard.

___
Python tracker 

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

[issue4826] exec() docstring bug about file objects

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Thanks! Fixed in r68301.

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

[issue4830] regrtest.py -u largefile test_io fails on OS X 10.5.6

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, you must indeed use the newly built python, that is "./python -m
test.regrtest [any arguments]".

Out of curiosity, why did you specifically run test_io? Any problem on
your platform?

--
nosy: +pitrou
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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file10527/DigiLink_esig_logo.jpg

___
Python tracker 

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file10525/DigiLink_esig_logo.jpg

___
Python tracker 

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file10526/unnamed

___
Python tracker 

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file10524/unnamed

___
Python tracker 

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file10033/unnamed

___
Python tracker 

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file10031/unnamed

___
Python tracker 

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

[issue3959] Add Google's ipaddr.py to the stdlib

[David Moss]

David Moss  added the comment:

> David, in the event of netaddr's complete or partial inclusion, 
> are you +1 with this and the maintenance of an ip/net library 
> in Python?

Yes, I would be very happy to help with this.

> If there's going to be lots of discussion, perhaps it should be 
> taken to python-dev?

Good idea.

Peter M. and the ipaddr contributors, are you all happy to proceed in
accordance with Duncan's suggestions? If so, let's kick off a thread on
python-dev to get the ball rolling and see what we can come up with.

___
Python tracker 

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

[issue4828] patch suggestion for webbrowser

[Yinon Ehrlich]

Changes by Yinon Ehrlich :


--
components: Library (Lib)
files: webbrowser.patch
keywords: patch
nosy: Yinon
severity: normal
status: open
title: patch suggestion for webbrowser
versions: Python 2.6
Added file: http://bugs.python.org/file12580/webbrowser.patch

___
Python tracker 

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

[issue4833] Explicit directories for zipfiles

[Robert Schuppenies]

New submission from Robert Schuppenies :

We have an issue with the Python cheeseshop which is probably an issue
with Python itself as well.

When we create a zip file with standard linux tools ('zip os-zipped.zip
*'), uploading it works fine. But if we use the zipfile module from
Python and try to upload the result to the cheeseshop, we get this error
message:

" Error unpacking zipfile:[Errno 2] No such file or directory: 
u'/data/packagedocs/Pympler/_sources/index.txt'"

Turns out that the Python-zipped version does not include explicit
directories. The OS-zipped version contains "directory/,
directory/asizeof.txt", the Python-zipped file only
"directory/asizeof.txt". Digging deeper, Python has no way to explicitly
add directories to a zip file.

It would be useful to have an option which allows the explicit creation
of directories inside of zip files. This would help when working with
applications which do not create directories if they are not explicitly
specified.

--
components: Library (Lib)
messages: 79070
nosy: schuppenies
severity: normal
status: open
title: Explicit directories for zipfiles
type: feature request

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Ralph Corderoy]

Changes by Ralph Corderoy :


___
Python tracker 

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

[issue4830] regrtest.py -u largefile test_io fails on OS X 10.5.6

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Do you know how to get python to  
> run from the locally built directory without installing it?

Well, precisely as I told you, but unfortunately it seems it doesn't
work for you.
I'm no Mac OS X user, so I advise you search the tracker for similar
problems, it seems the build procedure on Mac hasn't been polished yet
for Python 3.0.

(in any case, you can't run Python 3.0 scripts with Python 2.x, because
there have been a few syntax changes)

___
Python tracker 

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

[issue3638] Remove module level functions in _tkinter that depend on TkappObject

[STINNER Victor]

STINNER Victor  added the comment:

gpolo: Nice patches, good job and thanks ;-)

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Skip Montanaro]

Skip Montanaro  added the comment:

I'm sure this is the wrong place to bring this up, but I had a
thought about simple JIT compilation coupled with the opcode
dispatch changes in this issue.

Consider this silly function:

>>> def f(a, b):
...   result = 0
...   while b:
... result += a
... b -= 1
...   return result
... 

which compiles to

  2   0 LOAD_CONST   1 (0)
  3 STORE_FAST   2 (result)

  3   6 SETUP_LOOP  32 (to 41)
>>9 LOAD_FAST1 (b)
 12 JUMP_IF_FALSE   24 (to 39)
 15 POP_TOP 

  4  16 LOAD_FAST2 (result)
 19 LOAD_FAST0 (a)
 22 INPLACE_ADD 
 23 STORE_FAST   2 (result)

  5  26 LOAD_FAST1 (b)
 29 LOAD_CONST   2 (1)
 32 INPLACE_SUBTRACT
 33 STORE_FAST   1 (b)
 36 JUMP_ABSOLUTE9
>>   39 POP_TOP 
 40 POP_BLOCK   

  6 >>   41 LOAD_FAST2 (result)
 44 RETURN_VALUE

What if you built and compiled a "Mini Me" version of
PyEval_EvalFrameEx on-the-fly which only contained the prologue and
epilog of the real function and a small switch statement which only
knew about the the byte-code instructions used by f()?  Would the
compiler be better able to optimize the code?  Would the
instructions' placement nearer to each other provide better cache
behavior?  Would branch prediction by CPU be improved?

Another possibility would be to eliminate the for(;;) ... switch
altogether and just inline the code for the individual instructions.
It would help if the body of each bytecode instruction was
implemented as a macro, e.g.:

#define _POP_TOP() \
PREDICTED(POP_TOP); \
TARGET(POP_TOP) \
v = POP(); \
Py_DECREF(v); \
FAST_DISPATCH();

The above function could (lots of hand-waving here) be "compiled" to
something like

PyObject *
_MiniMe(PyFrameObject *f, int throwflag)
{
_PyEVAL_FRAMEEX_PROLOG

_LOAD_CONST(1)
_STORE_FAST(2)
_SETUP_LOOP(_41)
_9:
_LOAD_FAST(1)
_JUMP_IF_FALSE(_39)
_POP_TOP()
_LOAD_FAST(2)
_LOAD_FAST(0)
_INPLACE_ADD()
_STORE_FAST(2)
_26:
_LOAD_FAST(1)
_LOAD_CONST(2)
_INPLACE_SUBTRACT()
_STORE_FAST(1)
_JUMP_ABSOLUTE(_9)
_39:
_POP_TOP()
_POP_BLOCK()
_LOAD_FAST(2)
_RETURN_VALUE()

_PyEVAL_FRAMEEX_EPILOG
}

and the resulting binary code saved as an attribute of the code
object.  Presumably there would be some decision made about whether
to compile a function into this form (maybe only after it's been
called N times?).

___
Python tracker 

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

[issue4830] regrtest.py -u largefile test_io fails on OS X 10.5.6

[Cem Karan]

New submission from Cem Karan :

I'm running OS X 10.5.6 (uname -a == Darwin 9.6.0 Darwin Kernel Version 9.6.0: 
Mon Nov 
24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386) I get the 
following 
error after compiling Python 3.0.  Note that I have NOT installed it; I'm just 
trying 
to run the regression tests on the build.

Python-3.0 cfkaran2$ ./Lib/test/regrtest.py -u largefile test_io
  File "./Lib/test/regrtest.py", line 183
print(msg, file=sys.stderr)
   ^
SyntaxError: invalid syntax

I suspect that tester is not using the newly built python 3.0, but is using 
whatever 
is installed on the system, though I have not checked this at all.

--
components: Tests
messages: 79044
nosy: ironsmith
severity: normal
status: open
title: regrtest.py -u largefile test_io fails on OS X 10.5.6
type: crash
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

[issue3783] dbm.sqlite proof of concept

[Skip Montanaro]

Skip Montanaro  added the comment:

Hopefully I'm not picking at a scab here.  I updated the dbm.sqlite
module in the sandbox.  It now orders by rowid instead of by key.
(I saw no performance penalty for the small table sizes I was using
to ordering.  I switched from ordering by key to ordering by rowid
based on Gerhard's comment.

I got a big performance boost on writes by only committing once every
100 calls to __setitem__.  I still commit when deleting keys and 
explicitly commit when closing.

The main performance bottleneck now appears to be keys() and iterkeys().
I don't see how to make them any simpler.  Oddly enough, it seems
that iterkeys() is slower than keys().  Maybe it's just lack of sleep
but I can't see why this is so.

___
Python tracker 

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

[issue4010] configure options don't trickle down to distutils

[Roumen Petrov]

Roumen Petrov  added the comment:

May I propose a patch. The patch is only for linker flags(LDFLAGS). If
is accepted I will prepare another one for compiler flags.
The patch is not minimal. It is mostly cleanup patch.

For minimal patch - only change in Makefile.pre.in is enough.
Cleanup patch remove work-arounds for the issue.

Added file: http://bugs.python.org/file12583/py-issue-4010.patch

___
Python tracker 

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

[issue4834] Trouble configuring with icc on Mac OS X 10.5

[Skip Montanaro]

New submission from Skip Montanaro :

I get this error when trying to configure with Intel's icc on my Mac (Intel,
10.5.6, Xcode 3.1.2):

>> configure:10332: checking size of size_t
>> configure:10637: icc -o conftest -g -O2   conftest.c  >&5
>> ld: library not found for -lgcc_s

After a couple notes to python-dev and a little bit of sleuthing with -v I
discovered that it was generating -lgcc_s instead of -lgcc_s.10.5 in the ld
line.  I narrowed the problem down to this code in configure.in:

# Calculate the right deployment target for this build.
#
cur_target=`sw_vers -productVersion | sed 
's/\(10\.[[0-9]]*\).*/\1/'`
if test ${cur_target} '>' 10.2; then
cur_target=10.3
fi
if test "${UNIVERSAL_ARCHS}" = "all"; then
# Ensure that the default platform for a 4-way
# universal build is OSX 10.5, that's the first
# OS release where 4-way builds make sense.
cur_target='10.5'
fi

CONFIGURE_MACOSX_DEPLOYMENT_TARGET=${MACOSX_DEPLOYMENT_TARGET-${cur_target}}

# Make sure that MACOSX_DEPLOYMENT_TARGET is set in the 
# environment with a value that is the same as what we'll use
# in the Makefile to ensure that we'll get the same compiler
# environment during configure and build time.
MACOSX_DEPLOYMENT_TARGET="$CONFIGURE_MACOSX_DEPLOYMENT_TARGET"
export MACOSX_DEPLOYMENT_TARGET
EXPORT_MACOSX_DEPLOYMENT_TARGET=''

The test of cur_target against 10.2 seems suspicious.  This code dates from
r65061 (checked in by Benjamin last July) which states:

  #3381 fix framework builds on 10.4

Maybe it should be 

if test ${cur_target} '>' 10.2 -a ${cur_target} '<' 10.5 ; then
cur_target=10.3
fi

(which works).

Skip

--
messages: 79074
nosy: skip.montanaro
severity: normal
status: open
title: Trouble configuring with icc on Mac OS X 10.5

___
Python tracker 

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

[issue4835] SIZEOF_SOCKET_T not defined

[Skip Montanaro]

New submission from Skip Montanaro :

Compiling with Intel's icc I get lots of remarks like this:

icc -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes  -I. 
-IInclude -I../Include   -DPy_BUILD_CORE -o Parser/acceler.o ../Parser/acceler.c
../Include/longobject.h(35): remark #193: zero used for undefined 
preprocessing identifier "SIZEOF_SOCKET_T"
  #if SIZEOF_SOCKET_T <= SIZEOF_LONG
  ^

This is only defined in Modules/socketmodule.h.  It should probably be
defined somewhere else if it's to be referenced by longobject.h.

Skip

--
messages: 79075
nosy: skip.montanaro
severity: normal
status: open
title: SIZEOF_SOCKET_T not defined

___
Python tracker 

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

[issue4836] Idle Hangs on Wxit Button

[skillybob]

Changes by skillybob :


--
components: IDLE
nosy: skillybob
severity: normal
status: open
title: Idle Hangs on Wxit Button
type: behavior
versions: Python 2.6

___
Python tracker 

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

[issue4836] Idle Hangs on exit Button

[skillybob]

New submission from skillybob :

Bring up IDLE and type in any program. 
Run the module and it runs just fine. 
Try to use the Exit button of the running program and it hangs.
Pressing a second time will bring up a Windows dialog message that the
program is not responding . Click to kill the program and it return to
IDLE .  I have tried the programs with drPython and it works just fine .
I'm using Windows XP SP3 - Python 2.6.1 - and wxPython 2.8 (unicode) 
I have reinstalled Python 2.6.2 and 2.5.4 with no success - 
Any suggestions

--
title: Idle Hangs on Wxit Button -> Idle Hangs on exit Button

___
Python tracker 

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

[issue4136] merge json library with simplejson 2.0.3

[Martin v. Löwis]

Martin v. Löwis  added the comment:

http://codereview.appspot.com/7311/diff/1/8
File Lib/json/decoder.py (right):

http://codereview.appspot.com/7311/diff/1/8#newcode55
Line 55: def py_scanstring(s, end, encoding=None, strict=True,
_b=BACKSLASH, _m=STRINGCHUNK.match):
This function should get some comments what all the various cases are
(preferably speaking with the terms of JSON spec, i.e. chars, char, ...)

http://codereview.appspot.com/7311/diff/1/8#newcode71
Line 71: _append(content)
# 3 cases: end of string, control character, escape sequence

http://codereview.appspot.com/7311/diff/1/8#newcode76
Line 76: msg = "Invalid control character {0!r} at".format(esc)
esc isn't assigned until a few lines later. Is this really correct?

http://codereview.appspot.com/7311/diff/1/8#newcode104
Line 104: raise ValueError
No message?

http://codereview.appspot.com/7311/diff/1/8#newcode107
Line 107: raise ValueError
No message?

http://codereview.appspot.com/7311/diff/1/8#newcode111
Line 111: m = unichr(uni)
What's the purpose of m?

http://codereview.appspot.com/7311/diff/1/8#newcode127
Line 127: nextchar = s[end:end + 1]
Why not s[end]? Add comment if this is necessary.

http://codereview.appspot.com/7311/diff/1/8#newcode132
Line 132: nextchar = s[end:end + 1]
Likewise. There are more places where it does slicing, but also places
where it does indexing, in this function.

http://codereview.appspot.com/7311/diff/1/8#newcode290
Line 290: following strings: -Infinity, Infinity, NaN.
This sounds like an incompatible change.

http://codereview.appspot.com/7311/diff/1/8#newcode317
Line 317: def raw_decode(self, s, idx=0):
That looks like an incompatible change

http://codereview.appspot.com/7311/diff/1/9
File Modules/_json.c (right):

http://codereview.appspot.com/7311/diff/1/9#newcode196
Line 196: output_size *= 2;
You might want to check for integer overflow here.

http://codereview.appspot.com/7311/diff/1/9#newcode215
Line 215: ascii_escape_str(PyObject *pystr)
Please attach a comment to each function, telling what the function
does.

http://codereview.appspot.com/7311/diff/1/9#newcode733
Line 733: "..."
Some text should probably be added here.

http://codereview.appspot.com/7311/diff/1/9#newcode1320
Line 1320: if ((idx + 3 < length) && str[idx + 1] == 'u' && str[idx + 2]
== 'l' && str[idx + 3] == 'l') {
Is this really faster than a strncmp?

http://codereview.appspot.com/7311/diff/1/9#newcode1528
Line 1528: PyTypeObject PyScannerType = {
I think scanner objects should participate in cyclic gc.

http://codereview.appspot.com/7311/diff/1/9#newcode2025
Line 2025: "make_encoder",   /* tp_name */
That is a confusing type name. How about "Encoder"?

http://codereview.appspot.com/7311

--
title: merge json library with simplejson 2.0.4 -> merge json library with 
simplejson 2.0.3

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

> Removing the switch won't be possible unless we change the semantic
> EXTENDED_ARG. In addition, I doubt the improvement, if any, would worth
> the increased complexity.

Nevermind what I have said. I managed to remove switch pretty easily by
moving opcode fetching in the FAST_DISPATCH macro and abstracting the
control flow of the switch. There is no speed difference on pybench on
x86; on x86-64, the code is slower due to the opcode fetching change.

> I patched ceval.c to minimize f->last_i manipulations in the dispatch
> code.  On x86, I got an extra 9% speed up on pybench. However, the
> patch is a bit clumsy and a few unit tests are failing. I will see
> if I can improve it and open a new issue if worthwhile.

Nevermind that too. I found out f->last_i can be accessed anytime via
frame.getlineno(). So, you cannot really change how f->last_i is used
like I did.

___
Python tracker 

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

[issue4831] exec() behavior - revisited

[Georg Brandl]

Georg Brandl  added the comment:

> Please forgive me, but I'm really trying to wrap my brain around the 
> behavior of exec() in Python 3.   Here's a quote from the documentation:

>"In all cases, if the optional parts are omitted, the code is
> executed in the current scope."

> This is referring to the optional use of the globals/locals parameters 
> and seems to indicate that if they're omitted the code executes in the 
> scope where the exec() appeared.

That's right, but in some cases the locals can't be changed.  I'll
document this better.

> Now, I realize that exec() became a function in Python 3.  However, 
> regardless of that, is it really the intent that exec() not be allowed 
> to ever modify any local variable of a function?   In other words, do I 
> really have to do this?

> def foo():
> ldict = locals()
> exec("a=42",globals(),ldict)
> a = ldict['a']
> print(a)

Yes, if you really need "a" as a local afterwards.

> I would appreciate some greater clarity on this matter this go around.  
> Specifically, what is the approved way to have exec() modify the local 
> environment of a function?

There is none.  To modify the locals of a function on the fly is not
possible without several consequences: normally, function locals are not
stored in a dictionary, but an array, whose indices are determined at
compile time from the known locales.  This collides at least with new
locals added by exec.  The old exec statement circumvented this, because
the compiler knew that if an exec without globals/locals args occurred
in a function, that namespace would be "unoptimized", i.e. not using the
locals array.  Since exec() is now a normal function, the compiler does
not know what "exec" may be bound to, and therefore can not treat is
specially.

--
assignee:  -> georg.brandl
components: +Documentation -Interpreter Core
nosy: +georg.brandl

___
Python tracker 

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

[issue4815] idle 3.1a1 utf8

[Martin v. Löwis]

Martin v. Löwis  added the comment:

> utf8 has a special flag

No, it doesn't.

> as a special mark for editors.

That's the BOM, or UTF-8 signature. It's optional, and UTF-8-encoded
files typically do *not* have the UTF-8 signature.

> Even after making change in 
> it in IDLE, it does not became real utf8. 

Your understanding of UTF-8 is incorrect.

___
Python tracker 

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

[issue4676] python3 closes + home keys

[Somelauw]

Somelauw  added the comment:

I have found a way to reproduce this error:


Open the idle
Hold down shift:
   Press up 3 times
   Hold [fn] (on laptop)
   Press the home key
Idle closes for no reason


Any help?

___
Python tracker 

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

[issue4824] test_cmd_line failure on Mac OS X for py3k

[Mark Dickinson]

Mark Dickinson  added the comment:

Is this the same issue as issue 4388?

--
nosy: +marketdickinson

___
Python tracker 

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

[issue4831] exec() behavior - revisited

[Georg Brandl]

Georg Brandl  added the comment:

Yes, the dictionary will always contain "a" afterwards.

However, a cleaner way would be to use locals().copy(), or, if you don't
need current locals in the exec'd string, just a fresh dict.

In scopes not using the optimized locals, there may be some other
effects when using the dict returned by locals() directly:
* in module scopes, the dictionary returned by locals() is the same as
the globals() one
* in class scopes, the locals() dict is actually the local scope of the
class

___
Python tracker 

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

[issue4811] invalid reST markup in several documents

[Georg Brandl]

Georg Brandl  added the comment:

Thanks very much! I've added this to the Python doc tools in r68290.

___
Python tracker 

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

[issue4829] confusing error for file("foo", "w++")

[Ulrich Eckhardt]

New submission from Ulrich Eckhardt :

Specifying the '+' more than once while opening a file results in the
error "Must have exactly one of read/write/append mode". The attached
patch extends that with ".. and at most one optional plus".

Further, the patch checks these after the loop that parses the mode
string, avoiding some unnecessary gotos and saving a few lines of code
overall.

--
components: Interpreter Core
files: python-2.7-fopen-mode-parsing.0.patch
keywords: patch
messages: 79043
nosy: eckhardt
severity: normal
status: open
title: confusing error for file("foo", "w++")
type: behavior
versions: Python 2.7
Added file: 
http://bugs.python.org/file12581/python-2.7-fopen-mode-parsing.0.patch

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

> I managed to remove switch pretty easily by moving opcode fetching
> in the FAST_DISPATCH macro and abstracting the control flow of the
> switch.

Here is the diff against threadceval5.patch.

Added file: http://bugs.python.org/file12584/abstract-switch.diff

___
Python tracker 

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

[issue4831] exec() behavior - revisited

[David M. Beazley]

New submission from David M. Beazley :

Please forgive me, but I'm really trying to wrap my brain around the 
behavior of exec() in Python 3.   Here's a quote from the documentation:

   "In all cases, if the optional parts are omitted, the code is
executed in the current scope."

This is referring to the optional use of the globals/locals parameters 
and seems to indicate that if they're omitted the code executes in the 
scope where the exec() appeared.

Yet, this code fails:

def foo():
exec("a = 42")
print(a) # NameError: a

Now, I realize that exec() became a function in Python 3.  However, 
regardless of that, is it really the intent that exec() not be allowed 
to ever modify any local variable of a function?   In other words, do I 
really have to do this?

def foo():
ldict = locals()
exec("a=42",globals(),ldict)
a = ldict['a']
print(a)

I submitted a bug report about this once before and it was immediately 
dismissed.   

I would appreciate some greater clarity on this matter this go around.  
Specifically, what is the approved way to have exec() modify the local 
environment of a function?

--
components: Interpreter Core
messages: 79059
nosy: beazley
severity: normal
status: open
title: exec() behavior - revisited
type: behavior
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

[issue4815] idle 3.1a1 utf8

[Pavel Kosina]

Pavel Kosina  added the comment:

With this file  - hello.py (attached) - I should be also asked for
converting to utf8. When I open it, nothing changes, after making
changes and saving then the encodings is my windows standard cp1250 

Added file: http://bugs.python.org/file12582/hello.py

___
Python tracker 

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

[issue4824] test_cmd_line failure on Mac OS X for py3k

[Skip Montanaro]

Skip Montanaro  added the comment:

Yeah, looks like it.  Closing.

--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue1529269] Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

[Jörg Prante]

Jörg Prante  added the comment:

Modules/_ctypes/libffi/src/sparc/v8.S and
Modules/_ctypes/libffi/src/sparc/v9.S are SPARC assembler codes.

The python build process seems to pass the gcc compile flags to compile
these assembler source files.

It makes no sense if the debugging option -g is enabled, because C
source debugging code can not be generated in the case of assembler
code. The Solaris linker is also confused about this and might send the
relocation / alignment errors later.

So, as a workaround, just do not pass the gcc "-g" option to the python
build process when building with Solaris / gcc.

A clean solution would be to avoid gcc C compiler options being passed
to assembler source compiling in the python build process.

--
nosy: +jprante

___
Python tracker 

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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I have fixed issue4400, and I am back at work for this feature. 

I will propose it in Distutils-SIG to see what people think.

--
assignee:  -> tarek

___
Python tracker 

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

[issue4828] patch suggestion for webbrowser

[Yinon Ehrlich]

New submission from Yinon Ehrlich :

this will find applications/batch files  
ending with .com or .cmd too.

___
Python tracker 

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

[issue4524] Build fails at running build_scripts

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I will write an isolated test in distutils to reproduce this issue,

--
assignee:  -> tarek
components: +Distutils
nosy: +tarek

___
Python tracker 

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

[issue4706] try to build a C module, but don't worry if it doesn't work

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I can see two cases here:

1/ a compiler is not found, and build_ext can't proceed
2/ a compiler is found but it fails

For 2/, I don't think it's wise to fail silently if a compiler is found
and the build fails, because that can hide an unexpected problem.

For 1/ I would go for a binary distribution, or for a source
distribution that is specific to Linux in your case, if the extensions
are specific to other platforms. The latter could be done in the same
setup.py if needed by declaring the extensions only on matching platforms.

But I can see the benefit of a source distribution with optional
extensions in general. In that case, I think this option would have to
be declared optionally for each extension to be able to fail properly if
one extension is mandatory.

--
nosy: +tarek
priority:  -> normal
type:  -> feature request
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue4796] Decimal to receive from_float method

[Mark Dickinson]

Mark Dickinson  added the comment:

Raymond,

Do you think it would be worth replacing the two uses of
conditional expressions in Decimal.from_float with if-else
statements?

Alex Goretoy pointed out (on c.l.p) that the trunk version of
decimal.py can no longer be imported into Python 2.4 (and 2.3).
I don't know how much this matters, but it seems to go against
the comments about 2.3 compatibility at the top of decimal.py.
I admit that I don't really understand the motivation for these
comments, or whether they're still relevant 4 versions on
from Python 2.3.

Of course, from_float still won't work with earlier versions
of Python, but having one Decimal method unavailable seems
like a lesser crime than making 'import decimal' fail.

___
Python tracker 

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Jörg Prante]

Jörg Prante  added the comment:

Hi Bob, thank you for your patch. I spent hours on Solaris 10 SPARC to
get almost the same analysis. Just a detail, I ended up patching
$LDFLAGS in the SunOS 5 part in the configure.in file (like other
architectures like Darwin have set their LDFLAGS there, too).

Now I'm hoping that the Python team will accept this patch. Otherwise it
will be very hard and complicated for everybody else to set up a build
process for a 64-bit Python together with 32-bit Python on Solaris.

--
nosy: +jprante

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Facundo Batista]

Changes by Facundo Batista :


--
nosy: +facundobatista

___
Python tracker 

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

[issue4815] idle 3.1a1 utf8

[Martin v. Löwis]

Martin v. Löwis  added the comment:

> With this file  - hello.py (attached) - I should be also asked for
> converting to utf8.

Why that? This file is already encoded in utf-8 just fine. It is,
simultaneously, also encoded in ASCII, cp1250, cp1252, and nearly
any other encoding in use (as long as it is ASCII-based).

> When I open it, nothing changes, after making
> changes and saving then the encodings is my windows standard cp1250 

What did you do to find that out?

___
Python tracker 

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

[issue4010] configure options don't trickle down to distutils

[Roumen Petrov]

Roumen Petrov  added the comment:

correct patch uploaded

Added file: http://bugs.python.org/file12585/py-issue-4010.patch

___
Python tracker 

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

[issue4010] configure options don't trickle down to distutils

[Roumen Petrov]

Changes by Roumen Petrov :


Removed file: http://bugs.python.org/file12583/py-issue-4010.patch

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Ralph Corderoy]

Ralph Corderoy  added the comment:

Regarding compressing the opcode table to make better use of cache; 
what if the most frequently occurring opcodes where placed together,
e.g. the opcodes were ordered by frequency, most frequent first.  Just
based on a one-off static analysis of a body of code.  A level one cache
line can be, what, 64 bytes == 16 32-bit pointers.

--
nosy: +ralph.corderoy

___
Python tracker 

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

[issue4837] Omits MACHINE and DEBUG when building tix8.4.3

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto :

Currently, to install tix we need long command like this.

nmake -f python.mak TCL_MAJOR=8 TCL_MINOR=5 TCL_PATCH=2 MACHINE=IX86 
DEBUG=0 INSTALL_DIR=..\..\tcltk install

This patch enables us to omit MACHINE and DEBUG. (Precisely, can omit 
MACHINE if CPU is i386)

This patch is for http://svn.python.org/projects/external/tix-8.4.3.1

--
components: Build
files: python_mak_in_tix.patch
keywords: patch
messages: 79083
nosy: ocean-city
priority: low
severity: normal
status: open
title: Omits MACHINE and DEBUG when building tix8.4.3
versions: 3rd party
Added file: http://bugs.python.org/file12586/python_mak_in_tix.patch

___
Python tracker 

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Roumen Petrov]

Changes by Roumen Petrov :


--
nosy: +rpetrov

___
Python tracker 

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

[issue4796] Decimal to receive from_float method

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Do you think it would be worth replacing the two uses of
> conditional expressions in Decimal.from_float with if-else
> statements?

Yes, please.

> Of course, from_float still won't work with earlier versions
> of Python, but having one Decimal method unavailable seems
> like a lesser crime than making 'import decimal' fail.

Right.  I don't see an easy way around that short of having
a conditional compilation, allowing use of alternative slow
code multiplying the float repeatedly by two to build-up
the float digits.

___
Python tracker 

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

[issue1180] Option to ignore or substitute ~/.pydistutils.cfg

[Akira Kitada]

Changes by Akira Kitada :


--
nosy: +akitada

___
Python tracker 

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

[issue4676] python3 closes + home keys

[Daniel Diniz]

Daniel Diniz  added the comment:

I can't reproduce this with py3k on linux, but I do get a traceback in
the terminal used to launch idle:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/ajaksu/py3k/Lib/tkinter/__init__.py", line 1399, in __call__
return self.func(*args)
  File "/home/ajaksu/py3k/Lib/idlelib/MultiCall.py", line 165, in handler
r = l[i](event)
  File "/home/ajaksu/py3k/Lib/idlelib/EditorWindow.py", line 315, in
home_callback
if self.text.compare(first,">",last):
  File "/home/ajaksu/py3k/Lib/tkinter/__init__.py", line 2844, in compare
self._w, 'compare', index1, op, index2))
_tkinter.TclError: expected boolean value but got ""

That only happens sometimes happens, pressing home while holding shift
down does nothing but print the traceback. Else, pressing 'home' holding
shift alternates: start of line, start of indented block.

--
nosy: +ajaksu2

___
Python tracker 

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

[issue4272] set timestamp in gzip stream

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patches have been committed, thanks!

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

[issue4751] Patch for better thread support in hashlib

[Lukas Lueg]

Changes by Lukas Lueg :


Removed file: http://bugs.python.org/file12533/hashopenssl_threads-4.diff

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[Lukas Lueg]

Lukas Lueg  added the comment:

I've modified haypo's patch as commented. The object's lock should be
free 99.9% of the time so we try non-blocking first and can thereby skip
 releasing and re-locking the gil (to avoid a deadlock).

Added file: http://bugs.python.org/file12587/hashlibopenssl_small_lock-4.diff

___
Python tracker 

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

[issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86

[Mark Dickinson]

Mark Dickinson  added the comment:

Looking at this again, I don't like my solution.

I think it would be better to fix Py_IS_INFINITY directly, putting all the 
complication into one place;  then users of Py_IS_INFINITY don't have to 
spend time worrying about whether they should be calling Py_FORCE_DOUBLE 
or not.

The fixed Py_IS_INFINITY will likely be slower, but this only matters on 
platforms that don't provide isinf, isnan;  it seems that Solaris is the 
only such platform in common use.

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file12542/hashlibopenssl_small_lock-2.patch

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file12554/hashlibopenssl_small_lock-3.patch

___
Python tracker 

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

[issue4834] Trouble configuring with icc on Mac OS X 10.5

[Martin v. Löwis]

Martin v. Löwis  added the comment:

I don't think this is a bug. The change actually dates from r45800; I
believe the intention is that the Python binaries work on 10.3 and
newer, unless you use 10.2 or older to build them (in which case the
deployment target is set to the build machine version).

So I propose to reject this report as invalid.

--
nosy: +loewis

___
Python tracker 

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

[issue4757] reject unicode in zlib

[STINNER Victor]

STINNER Victor  added the comment:

> The fact that Python 2.x also accepts Unicode ASCII strings 
> where strings are normally expected is intended to help with 
> the migration to Unicode

I hate this behaviour. It doesn't help migration, it's the opposite! Sometimes 
it works (ASCII), and somtimes it fails (just one non-ASCII character). And 
then we will read "Unicode sucks!" because people doesn't understand the 
error.

> In Python 3.x, it's probably better to use bytes throughout the
> API.

I propose to reject unicode in Python 3.x and display a warning for Python 
2.x. A warning to prepare the migration... not to Unicode, but to Python3 ;-)

___
Python tracker 

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

[issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86

[Mark Dickinson]

Mark Dickinson  added the comment:

Tim, I'm in need of some advice on Py_IS_INFINITY.  It's currently
implemented (on platforms that don't provide isinf) as

#define Py_IS_INFINITY(X) ((X) && (X)*0.5 == (X))

I'd like to rewrite it as something like:

#define Py_IS_INFINITY_D(X) ((X) < -DBL_MAX || (X) > DBL_MAX)
#define Py_IS_INFINITY_F(X) ((X) < -FLT_MAX || (X) > FLT_MAX)
#define Py_IS_INFINITY(X) (sizeof(X) == sizeof(double) ? Py_IS_INFINITY_D(X) : 
Py_IS_INFINITY_F(X))

Are there any hidden (or obvious) numerical pitfalls with
this approach?

The reason for the rewrite is that the current Py_IS_INFINITY
can give false positives on x86 for values that are
pretending to be doubles, but are actually coming from an
80-bit x87 register.

--
nosy: +tim_one

___
Python tracker 

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

[issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86

[Mark Dickinson]

Mark Dickinson  added the comment:

s/false positives/false negatives/

___
Python tracker 

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

[issue4614] Document PyModule_Create()

[Martin v. Löwis]

Martin v. Löwis  added the comment:

The patch looks about right.

I believe it is a bug that md_state isn't automatically freed; m_free
should be used to release any resources stored inside md_state (or any
other resources that the module might hold). So please remove the note
on releasing md_state.

--
assignee: loewis -> georg.brandl

___
Python tracker 

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

[issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86

[Mark Dickinson]

Mark Dickinson  added the comment:

Answering my own question, there *are* pitfalls: (X) > DBL_LONG_MAX will 
evaluate to true for some finite extended precision values that are *just* 
larger than DBL_LONG_MAX, but nevertheless round to DBL_LONG_MAX rather 
than infinity.

Another not-so-bright idea down the drain...

___
Python tracker 

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

[issue4838] md_state is not released

[Martin v. Löwis]

New submission from Martin v. Löwis :

module_dealloc should free md_state if it is non-zero, after m_free was
called.

--
messages: 79095
nosy: loewis
priority: release blocker
severity: normal
status: open
title: md_state is not released
versions: 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

[issue4614] Document PyModule_Create()

[Georg Brandl]

Georg Brandl  added the comment:

OK, fixed up and committed as r68327.

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

[issue4834] Trouble configuring with icc on Mac OS X 10.5

[Skip Montanaro]

Skip Montanaro  added the comment:

Martin> I don't think this is a bug. The change actually dates from
Martin> r45800; I believe the intention is that the Python binaries work
Martin> on 10.3 and newer, unless you use 10.2 or older to build them
Martin> (in which case the deployment target is set to the build machine
Martin> version).

Martin> So I propose to reject this report as invalid.

I don't see how Python can require an optional piece of Xcode.  I only build
Python for my own use.  I shouldn't be forced to build exeutables which will
run on a version of the operating system I no longer have.  I think the code
in configure.in has to be smarter and detect that the presence or absence of
the 10.3 compatibility bits in Xcode.

Skip

___
Python tracker 

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

[issue3959] Add Google's ipaddr.py to the stdlib

[pmoody]

pmoody  added the comment:

> Good idea.
>
> Peter M. and the ipaddr contributors, are you all happy to proceed in
> accordance with Duncan's suggestions? If so, let's kick off a thread on
> python-dev to get the ball rolling and see what we can come up with.

I'm fine with this. But as Duncan mentioned, some guidance from the
benevolent powers that be on what exactly they're looking for before
we launch into a bunch of work would be appreciated.

Cheers,
/peter

___
Python tracker 

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

[issue3959] Add Google's ipaddr.py to the stdlib

[Martin v. Löwis]

Martin v. Löwis  added the comment:

> I'm fine with this. But as Duncan mentioned, some guidance from the
> benevolent powers that be on what exactly they're looking for before
> we launch into a bunch of work would be appreciated.

I think Guido's original message summarizes that: a module that
fills a gap for address manipulations... In addition, it should
have all the organisational qualities (happy user base, determined
maintainers, copyright forms, documentation, tests). As to what
precisely its API should be - that is for the experts (i.e. you)
to determine. I personally think performance is important, in
addition to a well-designed, useful API. Conformance to PEP 8
is also desirable.

___
Python tracker 

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

[issue4136] merge json library with simplejson 2.0.3

[Bob Ippolito]

Bob Ippolito  added the comment:

By "next patch" I'm referring to a currently nonexistent patch that 
would merge the json library with simplejson 2.0.7 (svn trunk at the 
moment). I may have time to create it next weekend.

---

http://codereview.appspot.com/7311/diff/1/8
File Lib/json/decoder.py (right):

http://codereview.appspot.com/7311/diff/1/8#newcode55
Line 55: def py_scanstring(s, end, encoding=None, strict=True,
_b=BACKSLASH, _m=STRINGCHUNK.match):
Commented in the next patch.


http://codereview.appspot.com/7311/diff/1/8#newcode71
Line 71: _append(content)
Commented in the next patch


http://codereview.appspot.com/7311/diff/1/8#newcode76
Line 76: msg = "Invalid control character {0!r} at".format(esc)
This is a bug in the exception handling code, fixed in the next patch.


http://codereview.appspot.com/7311/diff/1/8#newcode104
Line 104: raise ValueError
Exception is caught at the except block and re-raised with a message.
Next patch unrolls this so it's not confusing.


http://codereview.appspot.com/7311/diff/1/8#newcode107
Line 107: raise ValueError
Exception is caught at the except block and re-raised with a message.
Next patch unrolls this so it's not confusing.


http://codereview.appspot.com/7311/diff/1/8#newcode111
Line 111: m = unichr(uni)
Renamed m to char in the next patch.


http://codereview.appspot.com/7311/diff/1/8#newcode127
Line 127: nextchar = s[end:end + 1]
commented in next patch (only once). s[end] can raise an IndexError with
bad input, s[end:end+1] returns an empty string on underflow, which is
caught later with a more helpful error message.


http://codereview.appspot.com/7311/diff/1/8#newcode132
Line 132: nextchar = s[end:end + 1]
commented in next patch (only once). s[end] can raise an IndexError with
bad input, s[end:end+1] returns an empty string on underflow, which is
caught later with a more helpful error message.


http://codereview.appspot.com/7311/diff/1/8#newcode290
Line 290: following strings: -Infinity, Infinity, NaN.
Not practically speaking. The documented purpose of this callback is
"This can be used to raise an exception if invalid JSON numbers are
encountered.". I've never seen it used to handle None, True, False in a
different manner. That was more of an implementation detail than
anything else, and that is fixed by this patch. Existing implementations
of this callback will simply have dead code since they will never be
called with "null", "true" or "false" anymore.


http://codereview.appspot.com/7311/diff/1/8#newcode317
Line 317: def raw_decode(self, s, idx=0):
It is a compatible change.


http://codereview.appspot.com/7311/diff/1/9
File Modules/_json.c (right):

http://codereview.appspot.com/7311/diff/1/9#newcode196
Line 196: output_size *= 2;
_PyString_Resize checks for integer overflow, so it would explode there
just fine. The next patch changes this slightly to avoid unnecessary
calls to _PyString_Resize when the size didn't actually change, but
doesn't do any explicit integer overflow checking


http://codereview.appspot.com/7311/diff/1/9#newcode215
Line 215: ascii_escape_str(PyObject *pystr)
Done in the next patch


http://codereview.appspot.com/7311/diff/1/9#newcode733
Line 733: "..."
Done in the next patch.


http://codereview.appspot.com/7311/diff/1/9#newcode1320
Line 1320: if ((idx + 3 < length) && str[idx + 1] == 'u' && str[idx + 2]
== 'l' && str[idx + 3] == 'l') {
Probably not, but strncmp doesn't work for PyUnicode and the same code
is repeated there.


http://codereview.appspot.com/7311/diff/1/9#newcode1528
Line 1528: PyTypeObject PyScannerType = {
I don't think it's possible to cause a cycle using the documented APIs,
since the encoder is created and thrown away behind the scenes and never
passed to user code. Someone else can write that patch if it's
necessary.

http://codereview.appspot.com/7311/diff/1/9#newcode2025
Line 2025: "make_encoder",   /* tp_name */
It's not a type that's ever exposed to user code, make_encoder is
somewhat less confusing because that's the name it's exposed as. I'll
change it anyway though, it doesn't really matter since this is all
private API.

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

Is there anything I can do to move this forward at all?

cheers,

___
Python tracker 

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

[issue4626] compile() doesn't ignore the source encoding when a string is passed in

[STINNER Victor]

STINNER Victor  added the comment:

The function decode_str() (Parser/tokenizer.c) is responsible to 
detect the encoding using the BOM or the cookie ("coding: xxx"). 
decode_str() reencodes also the text to utf-8 if the encoding is 
different than utf-8. I think that we can just skip this function if 
the input text is already unicode (utf-8). Attached patch implements 
this idea.

The patch introduces a new compiler flag (PyCF_IGNORE_COOKIE) and a 
new parser flag (PyPARSE_IGNORE_COOKIE). The new compiler flag is set 
by source_as_string() when the input is a PyUnicode object. "Ignore 
cookie" is maybe not the best name for this flag.

With my patch, the first Brett's example displays:
   $ ./python com2.py
   Traceback (most recent call last):
 File "com2.py", line 3, in 
   compile(source, '', 'exec')
 File "", line 2
   ” = '”'
 ^
   SyntaxError: invalid character in identifier

The error cursor is not at the right column (bug related to the issue 
2382 or introduced by my patch?).

The patch changes the public API: PyTokenizer_FromString() prototype 
changed to get a new argument. I don't like changing public API. The 
new argument should be a bit vector (flags) instead of a single bit 
(ignore_cookie). We can avoid changing the public API by creating a 
new function (eg. "PyTokenizer_FromUnicode" ;-)). 

There are some old PyPARSE_xxx constants in Include/parsetok.h that 
might be removed. PyPARSE_WITH_IS_KEYWORD value is 3 which is strange 
since flags is a bit vector (changed with | and tested by &). But 
PyPARSE_WITH_IS_KEYWORD is a dead constant (written in #if 
0...#endif).

--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file12588/tokenizer_ignore_cookie.patch

___
Python tracker 

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

[issue4626] compile() doesn't ignore the source encoding when a string is passed in

[STINNER Victor]

STINNER Victor  added the comment:

Oops, I attached the wrong file :-p

Added file: http://bugs.python.org/file12589/tokenizer_ignore_cookie-2.patch

___
Python tracker 

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

[issue4626] compile() doesn't ignore the source encoding when a string is passed in

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file12588/tokenizer_ignore_cookie.patch

___
Python tracker 

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

[issue4626] compile() doesn't ignore the source encoding when a string is passed in

[STINNER Victor]

STINNER Victor  added the comment:

> With my patch, the first Brett's example displays:
>...
>” = '”'
>  ^
>SyntaxError: invalid character in identifier
>
> The error cursor is not at the right column (bug related to the issue
> 2382 or introduced by my patch?).

I tried py3k_adjust_cursor_at_syntax_error_v2.patch (issue #2382) and the 
cursor is displayed at the right column:

   $ ./python com2.py
   Traceback (most recent call last):
 ...
 File "", line 2
   ” = '”'
   ^

So it's not a new bug ;-)

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Paolo 'Blaisorblade' Giarrusso]

Paolo 'Blaisorblade' Giarrusso  added the comment:

@alexandre: if you add two labels per opcode and two dispatch tables,
one before (like now) and one after the parameter fetch (where we have
the 'case'), you can keep the same speed.
And under the hood we also had two dispatch tables before, with the
switch, so it's not a big deal; finally, the second table is only used
in the slow path (i.e. EXTENDED_ARG, or when additional checks are needed).

About f->last_i, when I have time I want to try optimizing it. Somewhere
you can be sure it's not going to be used.
But you have some changes about that in the abstract-switch patch, I
think that was not intended?

___
Python tracker 

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

[issue4839] Reminder: Please Respond to Manas's Invitation

[Benjamin Peterson]

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

[issue4840] Compile dbm in Ubuntu

[Charles Hans]

New submission from Charles Hans :

I tried and failed in compile python 3.0 in ubuntu 8.10. Then I found
the scripts in setup.py use "gdbm/ndbm.h" while in ubuntu 8.10 it should
be gdbm-ndbm.h. So I made the following change which make the compiling ok:


setup.py

787c787
<   and find_file("gdbm/ndbm.h", inc_dirs, []) is not None):
---
>   and find_file("gdbm-ndbm.h", inc_dirs, []) is not None):
790c790
libraries = ['gdbm',
'gdbm_compat'] ) )


Modules/_dbmodule.c

22c22
< #include 
---
> #include 

--
components: Library (Lib)
messages: 79107
nosy: cwhan
severity: normal
status: open
title: Compile dbm in Ubuntu
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

[issue4836] Idle Hangs on exit Button

[Terry Helge]

Terry Helge  added the comment:

Additional testing -- apparently this is only happening when I run a
program that imports pyGame. If I run IDLE and do not import, it
functions properly .

___
Python tracker 

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

[issue4836] Idle Hangs on exit Button

[Terry Helge]

Terry Helge  added the comment:

Additional testing - ran programs that call (import) pyGame using
drPython and everything works fine ... just when using IDLE and pyGame
am I getting this action. Rats!!

___
Python tracker 

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

[issue4757] reject unicode in zlib

[Lukas Lueg]

Lukas Lueg  added the comment:

The current behaviour may help the majority by ignorance and cause weird
errors for others. We tell people that Python distincts between Text and
Data but actually treat it all the same by implicit encoding.

Modules that only operate on Bytes should reject Unicode-objects in
Python3; it's a matter of 3 lines to display a warning in Python 2.
Those modules that usually operate on Text but have single functions
that operate on Bytes should display a warning but not enforce explicit
encoding.

Also see #4821 and #4818 where unicode already got rejected by the
openssl-driven classes but silently accepted by the build-in ones.

___
Python tracker 

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