[issue2939] Apache mod_python python-func strftime

[Sabine Nitsch]

New submission from Sabine Nitsch <[EMAIL PROTECTED]>:

If you use the python-function strftime unter apache within mod_python
the function delivers as date the last startdate of apache and not the
current date.

--
assignee: theller
components: ctypes
messages: 67182
nosy: raisachrisgun, theller
severity: normal
status: open
title: Apache mod_python python-func strftime
type: behavior
versions: Python 2.4

__
Tracker <[EMAIL PROTECTED]>

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

[issue2940] Building Python fails on SunOS

[Adrian M]

New submission from Adrian M <[EMAIL PROTECTED]>:

$ uname -a
SunOS ro1estw 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Fire-880

gcc 2.6.3   


When running ./configure I'm getting warnings like: 
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h: check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h: section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take
precedence

This happens for many other headers as well (dlfcn.h, fcntl.h, and many
others  - i'll attach the whole list of messages). 

Then, the ./configure step ends with the following message :
checking size of int... configure: error: cannot compute sizeof (int)

--
components: Build
files: config_logs.zip
messages: 67183
nosy: syraxes
severity: normal
status: open
title: Building Python fails on SunOS
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file10397/config_logs.zip

__
Tracker <[EMAIL PROTECTED]>

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

[issue2941] Propagate define to resurce mingw32 compile

[Alexandr Zamaraev]

New submission from Alexandr Zamaraev <[EMAIL PROTECTED]>:

If resource source file depend from macros definition passing from
define_macros parametr setup crash.

--
components: Distutils
files: cygwinccompiler.diff
keywords: patch
messages: 67184
nosy: shura_zam
severity: normal
status: open
title: Propagate define to resurce mingw32 compile
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10398/cygwinccompiler.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2942] mingw/cygwin do not accept asm file as extension source

[Alexandr Zamaraev]

New submission from Alexandr Zamaraev <[EMAIL PROTECTED]>:

mingw/cygwin do not accept asm file as extension source

--
components: Distutils
files: cygwinccompiler.diff
keywords: patch
messages: 67185
nosy: shura_zam
severity: normal
status: open
title: mingw/cygwin do not accept asm file as extension source
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10399/cygwinccompiler.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2939] Apache mod_python python-func strftime

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

Has nothing to do with ctypes.

--
assignee: theller -> 

__
Tracker <[EMAIL PROTECTED]>

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

[issue2943] Distutils should generate a better error message when the SDK is not installed

[Cournapeau David]

New submission from Cournapeau David <[EMAIL PROTECTED]>:

I tried to build some extensions with python 2.6 (built from sources
with VS 2008 express), and got some errors in the function
query_vcvarsall. The offending lines are:

if len(result) != len(interesting):
raise ValueError(str(list(result.keys(

I got a value error here. After some investigation, I realized that it
was because I did not install the SDK. I think the error message could
be isgnificantly improved if installing the SDK was suggested in the
exception message.

--
components: Distutils
messages: 67187
nosy: cdavid
severity: normal
status: open
title: Distutils should generate a better error message when the SDK is not 
installed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2944] asyncore doesn't handle connection refused correctly

[Alexander Shigin]

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

Patch against r63534 fix the issue.

--
keywords: +patch
Added file: http://bugs.python.org/file10401/asyncore-connect-patch.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2944] asyncore doesn't handle connection refused correctly

[Alexander Shigin]

New submission from Alexander Shigin <[EMAIL PROTECTED]>:

Unix select returns socket in read fd set and write fd set if 
nonblocking socket attempts to connect to unaviable address. 

asyncore should check this case by calling getsockopt with SO_ERROR 
optname. If return value is 0 it should call handle_connect_event, 
otherwise if should call handle_expt_event.

Attached file prints "get exception" if asyncore can't connect to 
remote side, not "uncaptured python exception"

Patches from Issue1736190 do not fix this case.

--
components: Library (Lib)
files: test_async_connect.py
messages: 67188
nosy: shigin
severity: normal
status: open
title: asyncore doesn't handle connection refused correctly
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10400/test_async_connect.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Jesús Cea Avión]

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>:


--
nosy: +jcea


Tracker <[EMAIL PROTECTED]>


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

[issue643841] New class special method lookup change

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Added documentation, and assigned to Barry as release manager for 2.6/3.0.

Also bumped to 'release blocker' status because I think the loss of
classic classes transparent proxying capabilities is a fairly
substantial issue that needs to be addressed explicitly before the first
3.0 beta.

If I get the go-ahead from Barry or Guido, I'll add the new module to
2.6 (from whence it will be migrated to 3.0 as part of the normal merge
process).

--
assignee: georg.brandl -> barry
nosy: +barry -jcea
priority: normal -> release blocker
Added file: http://bugs.python.org/file10402/typetools.rst


Tracker <[EMAIL PROTECTED]>


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

[issue643841] New class special method lookup change

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Also changed to a library issue instead of a docs issue.

--
components: +Library (Lib) -Documentation


Tracker <[EMAIL PROTECTED]>


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

[issue2945] bdist_rpm does not list dist files (should effect upload)

[Hartmut Goebel]

New submission from Hartmut Goebel <[EMAIL PROTECTED]>:

In Python 2.5 distutils has a bug in bdist_rpm:

Generated distribution files are not listed in
``distribution.dist_files``. Thus .rpms can not be handled by other
tools, eg. ``upload``.

I need this bug fixed for automated upload of files using
.

Enclosed please find a simple package to show the bug. Just run

python setup.py bdist_rpm

and watch the (missing) output. In contrast see the output of

python setup.py sdist

Additionally:
While untested, this should effect distutils ``upload`` command. RPMs
are not in the dist_files list and when looking at the source, there
seams to be no 'trick' to add them later.

--
components: Distutils
files: simple-0.0.0.0.1.tar.gz
messages: 67192
nosy: htgoebel
severity: normal
status: open
title: bdist_rpm does not list dist files (should effect upload)
versions: Python 2.5
Added file: http://bugs.python.org/file10403/simple-0.0.0.0.1.tar.gz

__
Tracker <[EMAIL PROTECTED]>

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

[issue2945] bdist_rpm does not list dist files (should effect upload)

[Hartmut Goebel]

Changes by Hartmut Goebel <[EMAIL PROTECTED]>:


--
type:  -> behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue2946] setuptools: bdist_wininst adds duplicate entry to dist_files

[Hartmut Goebel]

New submission from Hartmut Goebel <[EMAIL PROTECTED]>:

In setuptools 0.6c8 has a bug in bdist_wininst:

Distribution files are listed twice
``distribution.dist_files``. This hinders developing tools which use
this data. In addition ``upload`` will upload the file twice to pypi.

I need this bug fixed for automated upload of files using
;.

Enclosed please find a simple package to show the bug. Just run

   python setup.py bdist_wininst

this shows one entry. Now run

   python setup-setuptools.py bdist_wininst

this shows two entires.

The only difference between both setup files is wherefrom setup() is
imported.

--
components: Distutils
files: simple-0.0.0.0.1.tar.gz
messages: 67193
nosy: htgoebel
severity: normal
status: open
title: setuptools: bdist_wininst adds duplicate entry to dist_files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10404/simple-0.0.0.0.1.tar.gz

__
Tracker <[EMAIL PROTECTED]>

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

[issue2937] Incorrect rounding in floating-point operations with gcc/x87

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Okay; so this is definitely not a Python bug---it's a well-known
and well-documented problem with IA32 floating-point.  And I accept
that it's really not Python's responsibility to document this, either.

Nevertheless, it was a surprise to me when my (supposedly IEEE 754
compliant) Pentium 4 box produced this.  I probably shouldn't have
been surprised. I'm aware of issues with 80-bit extended precision when 
programming in C, but naively expected that Python would be largely 
immune from these, since it's always going to force intermediate results 
from (80-bit) floating-point registers into (64-bit) memory slots.

There's an excellent recent article by David Monniaux, "The pitfalls of
verifying floating-point computations.", that's available online at

http://hal.archives-ouvertes.fr/hal-00128124

that explains exactly what's going on here (it's a case of double-
rounding, as described in section 3.1.2 of that paper).

Do you think a documentation patch that added this reference, along with 
the oft-quoted "What Every Computer Scientist Should Know About 
Floating-Point Arithmetic" by David Goldberg, to Appendix B of the 
tutorial would be acceptable?

One other thing that's worth mentioning:  on Pentium 4 and later, the
gcc flags "-mfpmath=sse -msse2" appear to fix the problem, by forcing 
gcc to use the SSE floating-point unit instead of the x87-derived one.

In any case, I guess this report should be closed as 'invalid', but I 
hope that at least others who encounter this problem manage to find this 
bug report.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2947] subprocess (Replacing popen) - add a warning / hint

[Helmut Jarausch]

New submission from Helmut Jarausch <[EMAIL PROTECTED]>:

Background:
I (as many others, too) have used the following code in the past

ARC='MyDumpFile'
tar_inp= os.popen('/bin/tar cjf '+ARC+' -T -','w')

tar_exit_code= tar_inp.close()
if  tar_exit_code != None and tar_exit_code % 256 :
  print "some error messages"

When replacing this - as suggested - by

TAR= Popen(('/bin/tar','cjf',ARC,'-T','-'),stdin=PIPE)
tar_inp= TAR.stdin

tar_inp.close() always returns None which was an indication
of NO ERROR when used together with popen.

So this has proabaly to be replaced by

tar_inp.close()
tar_exit_code= TAR.wait()

if  tar_exit_code != 0 :
  print "some error messages"


I suggest a warning / hint to change checking for errors
when upgrading to subprocess.Popen

--
assignee: georg.brandl
components: Documentation
messages: 67195
nosy: HWJ, georg.brandl
severity: normal
status: open
title: subprocess (Replacing popen) - add a warning / hint
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2944] asyncore doesn't handle connection refused correctly

[Alexander Shigin]

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

Oh, I've just realised that FreeBSD is too fast. test_async_connect.py 
works fine on linux box, but on FreeBSD i need to change localhost to 
another host :(

I haven't got any idea how to make a test case which work on any 
machine.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2819] Full precision summation

[Jean Brouwers]

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

Attached is revision 11 of the mathmodule.c patch for Python 2.6a3.  

This one includes Raymond's full precision summation, Mark's rounding 
partials addition and correct non-finites and error handling.

However, intermediate overflow will raise an OverflowError and a 
FLT_RADIX not equal 2 cause a NotImplementedError.

An updated test_math_sum11.py script is also attached.  All test cases 
pass on 5 different builds of Python 2.6a3:

- 32-bit MacOS X 10.4.11 (Intel) with gcc 4.0.1
- 32-bit MacOS X 10.3.9 (PPC) with gcc 3.3
- 64-bit RHEL 3 update 7 (Opteron) using gcc 4.1.2
- 32- and 64-bit Solaris 10 (Opteron) with Sun C 5.8.

/Jean Brouwers

Added file: http://bugs.python.org/file10405/mathmodule11.c.2.6a3.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2819] Full precision summation

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10406/test_math_sum11.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2819] Full precision summation

[Jean Brouwers]

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

Here is rev 12 of the mathmodule.c patch.  It is the same as rev 11 but 
with additional code removed as requested:

- no FLT_RADIX 2 check
- no errno illustration in _do_sum_add2()
- no _do_sum() callback function argument
- no option 'start' argument for math.sum.

The test_math.sum12.py script and results are the same as rev 11.

/Jean Brouwers

Added file: http://bugs.python.org/file10407/mathmodule12.c.2.6a3.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2819] Full precision summation

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10408/test_math_sum12.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface

[Kurt B. Kaiser]

Changes by Kurt B. Kaiser <[EMAIL PROTECTED]>:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1948] Cant open python gui using VISTA

[Kurt B. Kaiser]

Kurt B. Kaiser <[EMAIL PROTECTED]> added the comment:

No response from OP, closing.

--
resolution:  -> works for me
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

[issue2584] numeric overflow in IDLE

[Kurt B. Kaiser]

Kurt B. Kaiser <[EMAIL PROTECTED]> added the comment:

When this is running, what happens if you hit Control-c a few times, 
especially in the first few seconds?  Does it abort with a 
KeyboardInterrupt? Does it stop responding to Control-c after the window 
fills up?

Note that IDLE slows down when very large quantities of text are printed 
to the shell window.  This is an issue with the Tk library.

The subprocess is supposed to exit when it notices that the socket has 
closed.  This doesn't work well on Windows, unfortunately.  We are 
thinking about it ;-)

It doesn't seem that what you are attempting to fix has any realistic 
application.

I don't run Vista.  Check your resources right after you start your 
code.  Is your system unresponsive because you are running out of memory 
or because you are using CPU 100%?


Patient: My head hurts when I bang it against a wall.
Doctor: So, don't do that!

__
Tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Adam Olsen]

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

_deref won't work for remote objects, will it?  Nor _unwrap, although
that starts to get "fun".


Tracker <[EMAIL PROTECTED]>


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

[issue2913] idlelib/EditorWindow.py uses xrange()

[Kurt B. Kaiser]

Changes by Kurt B. Kaiser <[EMAIL PROTECTED]>:


--
assignee:  -> kbk
nosy: +kbk

__
Tracker <[EMAIL PROTECTED]>

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

[issue2799] Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

[Haoyu Bai]

Changes by Haoyu Bai <[EMAIL PROTECTED]>:


--
nosy: +bhy

__
Tracker <[EMAIL PROTECTED]>

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

[issue2584] numeric overflow in IDLE

[Kurt B. Kaiser]

Kurt B. Kaiser <[EMAIL PROTECTED]> added the comment:

BTW, instead of a reboot, use Task Manager (or whatever they needlessly 
renamed it to on Vista :) to kill all python processes.  That should free 
up your machine.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2940] Building Python fails on SunOS

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Why do you think this is a bug in Python?

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue2946] setuptools: bdist_wininst adds duplicate entry to dist_files

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Is that a bug in setuptools? If so, don't report it here - setuptools is
a separate project, not part of the core Python (bdist_wininst is part
of distutils).

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1798] Add ctypes calling convention that allows safe access of errno

[Armin Rigo]

Armin Rigo <[EMAIL PROTECTED]> added the comment:

Alternatively, we can try to make ctypes "feel like" C itself:

 ctypes.set_errno(0)
 while True:
 dirent = linux_c_lib.readdir(byref(dir))
 if not dirent:
 if ctypes.get_errno() == 0:
 break
 else:
 raise IOError("oups!")

We are doing this kind of thing in PyPy with the "rffi" foreign function
interface.  To achieve this result, ctypes would have to maintain
internally an internal, global (but thread-local) variable representing
the current errno value.  Just before doing a C library function call,
ctypes would copy this variable into the real C-level errno; and
immediately after the call it would read the C-level errno back into its
internal variable.  In this way, other calls to C functions unrelated to
ctypes don't interfere.  The get_errno() and set_errno() functions
merely access the thread-local variable (not the real C-level errno).

--
nosy: +arigo

__
Tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Correct, this isn't intended to be an all-singing, all-dancing proxy
implementation - it's meant to be a simple solution for local proxies
that want to change the behaviour of a few operations while leaving
other operations unaffected.

The proposed documentation I uploaded covers some of its limitations.
However, even for those cases, ProxyMixin and/or
test_typetools.TestProxyMixin can be used as a reference to make sure a
custom proxy implementation correctly handles all the special method
invocations that can bypass __getattribute__.


Tracker <[EMAIL PROTECTED]>


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

[issue2584] numeric overflow in IDLE

[Tim Wilcoxson]

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

I guess my only reply isfair enough.

heh.

On Thu, May 22, 2008 at 1:07 PM, Kurt B. Kaiser <[EMAIL PROTECTED]>
wrote:

>
> Kurt B. Kaiser <[EMAIL PROTECTED]> added the comment:
>
> When this is running, what happens if you hit Control-c a few times,
> especially in the first few seconds?  Does it abort with a
> KeyboardInterrupt? Does it stop responding to Control-c after the window
> fills up?
>
> Note that IDLE slows down when very large quantities of text are printed
> to the shell window.  This is an issue with the Tk library.
>
> The subprocess is supposed to exit when it notices that the socket has
> closed.  This doesn't work well on Windows, unfortunately.  We are
> thinking about it ;-)
>
> It doesn't seem that what you are attempting to fix has any realistic
> application.
>
> I don't run Vista.  Check your resources right after you start your
> code.  Is your system unresponsive because you are running out of memory
> or because you are using CPU 100%?
>
>
> Patient: My head hurts when I bang it against a wall.
> Doctor: So, don't do that!
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

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

__
Tracker <[EMAIL PROTECTED]>

__I guess my only reply isfair enough. heh.On Thu, May 22, 2008 at 1:07 PM, Kurt B. Kaiser [EMAIL PROTECTED]> wrote:

Kurt B. Kaiser [EMAIL PROTECTED]> 
added the comment:

When this is running, what happens if you hit Control-c a few times,
especially in the first few seconds?  Does it abort with a
KeyboardInterrupt? Does it stop responding to Control-c after the window
fills up?

Note that IDLE slows down when very large quantities of text are printed
to the shell window.  This is an issue with the Tk library.

The subprocess is supposed to exit when it notices that the socket has
closed.  This doesn't work well on Windows, unfortunately.  We 
are
thinking about it ;-)

It doesn't seem that what you are attempting to fix has any realistic
application.

I don't run Vista.  Check your resources right after you start your
code.  Is your system unresponsive because you are running out of 
memory
or because you are using CPU 100%?


Patient: My head hurts when I bang it against a wall.
Doctor: So, don't do that!

__
Tracker [EMAIL PROTECTED]>
http://bugs.python.org/issue2584>
__

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

[issue643841] New class special method lookup change

[Adam Olsen]

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

If it's so specialized then I'm not sure it should be in the stdlib -
maybe as a private API, if there was a user.

Having a reference implementation is noble, but this isn't the right way
to do it.  Maybe as an example in Doc or in the cookbook.  Better yet,
add the unit test and define the ProxyMixin directly in that file.


Tracker <[EMAIL PROTECTED]>


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

[issue643841] New class special method lookup change

[Jesús Cea Avión]

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>:


--
nosy: +jcea


Tracker <[EMAIL PROTECTED]>


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

[issue2819] Full precision summation

[Jean Brouwers]

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

Here is another, cleaner revision 19 of the same mathmodule.c patch and 
the corresponding test_math_sum19.py script.

/Jean Brouwers

Added file: http://bugs.python.org/file10410/mathmodule19.c.2.6a3.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2819] Full precision summation

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10411/test_math_sum19.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2819] Full precision summation

[Raymond Hettinger]

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

Nice work Jean.  Marking the patch accepted. Mark please go ahead with 
commit.  

Once the commit has settled for a couple of days, go ahead with a 
separate patch to cover the rest of 754R logic for special values. 

After that one settles, close this issue and open a new one for a 
comparable patch in cmath.

--
assignee: rhettinger -> marketdickinson
resolution:  -> accepted

__
Tracker <[EMAIL PROTECTED]>

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

[issue2819] Full precision summation

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

math module patch committed, r63542.

I'm still working on converting the tests to the unittest framework.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2819] Full precision summation

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Tests committed in r63543

__
Tracker <[EMAIL PROTECTED]>

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

[issue2948] Unicode support for hashing algorithms

[Vasco Rodrigues]

New submission from Vasco Rodrigues <[EMAIL PROTECTED]>:

The hashing algorithms don't support Unicode. Any Unicode text given to
them is first tried to convert ascii and then hashed. Not all strings
are convertible to ascii.
Now that Unicode is becoming the default encoding, specially for the web
side of python, where a lot of this hashing algorithms are used.
There should be some kind of Unicode support in them.

Example:
from hashlib import md5
md5(u'joão')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe3' in
position 2: ordinal not in range(128)

--
components: Unicode
messages: 67214
nosy: vvro
severity: normal
status: open
title: Unicode support for hashing algorithms
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2948] Unicode support for hashing algorithms

[Raymond Hettinger]

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

I don't think this is the right thing to do.  The hash algorithms are 
defined in terms of bytes, but Unicode is an abstracted from a byte 
level encoding.  It doesn't make sense to convert using an arbitrary 
encoding (such as UTF-8) because someone else might hash the same text 
using a different encoding.

Mark, do you concur?

--
assignee:  -> lemburg
nosy: +lemburg, rhettinger
type:  -> feature request
versions: +Python 2.6 -Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2948] Unicode support for hashing algorithms

[Vasco Rodrigues]

Vasco Rodrigues <[EMAIL PROTECTED]> added the comment:

You could just make a check for unicode strings and issue the encode in
the hash function.
I understand the byte abstraction, but if you issue an encode on a
unicode string with only ascii chars it gets converted to the same in
ascii, result will be the same.

So i got to do md5(u'joão'.encode("utf-8"))?
Wasn't unicode becoming the default?

If I do md5(u'john'), it works. And that's a unicode string. It should
have told me, no unicode then...

__
Tracker <[EMAIL PROTECTED]>

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

[issue2948] Unicode support for hashing algorithms

[Vasco Rodrigues]

Changes by Vasco Rodrigues <[EMAIL PROTECTED]>:


--
versions: +Python 2.4, Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2880] Rename repr to reprlib

[Brett Cannon]

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

r635647 and r635649 reverted the module in 3.0.

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

[issue2775] Implement PEP 3108

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
dependencies:  -Rename repr to reprlib

__
Tracker <[EMAIL PROTECTED]>

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

[issue2948] Unicode support for hashing algorithms

[Raymond Hettinger]

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

Only 2.6 should be marked.  This is a feature request for an implicit 
conversion with a default encoding; it is not a bugfix.

FWIW, here's a reference to an earlier discussion:
http://mail.python.org/pipermail/python-list/2004-April/258630.html

Also, it is unpersuasive that md5() works with u'john'.  That is just 
an artifact of the 2.x series.  In 3.0, there is a more clear 
distinction between bytes and text.

Recommending that this be rejected and closed.  Without a universally 
accepted (not just with Python) implicit coding, there's no way to 
check MD5 checksums match for the same unicode text.

--
priority:  -> low
versions:  -Python 2.4, Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2948] Unicode support for hashing algorithms

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I'm rejecting this idea, for the reasons already given by others: the
same string might have different hash values, depending on which
encoding is chosen. Users will have to be explicit when hashing, just as
they need to be explicit when they chose a hash algorithm (i.e. md5,
sha1, or sha256 - they all do the same thing, but still produce
different output).

If you want a hash algorithm that abstracts from these details, use the
builtin hash function:

py> hash(u'joão')
679553179

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