[issue11039] Use of 'L' specifier is inconsistent when printing long integers

2011-01-28 Thread Konstantin Osipov 

New submission from Konstantin Osipov kostja.osi...@gmail.com:

I'm using a 64 bit system, but the issue is as well repeatable on 32 bit 
systems: 

kostja@shmita:~$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
 0x
18446744073709551615L
 [0x]
[18446744073709551615L]
 str(0x)
'18446744073709551615'
 str([0x])
'[18446744073709551615L]'

Notice the 'L' specifier disappears when creating a string from an integer. 
I.e. depending on conversion order, 'L' specifier is present or absent in the 
resulting string representation.

I don't know the reason why 'L' specifier is necessary at all when printing 
integers, rather, I'd say it's very harmful, because makes Python program 
platform-dependent (since int is mapped to C long, 32-bit systems print 'L' 
where 64-bit systems don't), but please at least make the output consistent!

Thanks,
-- 
kostja

--
components: None
messages: 127284
nosy: kostja
priority: normal
severity: normal
status: open
title: Use of 'L' specifier is inconsistent when printing long integers
versions: Python 2.6

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

[issue3766] socket.socket.recv broken (unbearably slow)

2010-12-31 Thread Konstantin Osipov 

Konstantin Osipov kostja.osi...@gmail.com added the comment:

I was able to observe the same issue:

I'm using Python 2.6.5 on Ubuntu 10.0.4 LTS. My system is 64 bit Intel Core I7, 
Quad core, Linux kernel 2.6.32-generic x86_64, Ubuntu EGLIBC 2.11.1-0ubuntu7.5.

A simple client TCP socket, which sends 35 bytes over to a server on localhost 
and receives 20 bytes in response, produces only 22 RPS. An identical 
application written in C gives me 7000 RPS. TCP_NODELAY is on on the server 
side. Turning on TCP_NODELAY on the client gives me ~500 RPS in Python (which 
I'm satisfied with, 'cause I think I then hit other bottlenecks). 
Still, such low performance on by default can be surprising and hard to debug.

--
nosy: +kostja

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