[issue5289] ctypes.util.find_library does not work under Solaris

[Ke Wang]

New submission from Ke Wang :

Under Solaris, find_library can not give the correct path.
Solaris does not have /sbin/ldconfig, so _findLib_gcc is used.

def _findLib_gcc(name):
expr = r'[^\(\)\s]*lib%s\.[^\(\)\s]*' % re.escape(name)
fdout, ccout = tempfile.mkstemp()
os.close(fdout)
cmd = 'if type gcc >/dev/null 2>&1; then CC=gcc; else CC=cc; fi;' \
  '$CC -Wl,-t -o ' + ccout + ' 2>&1 -l' + name
try:
f = os.popen(cmd)
trace = f.read()
f.close()
finally:
try:
os.unlink(ccout)
except OSError, e:
if e.errno != errno.ENOENT:
raise
res = re.search(expr, trace)
if not res:
return None
return res.group(0)

I executed these code manually, and after ‘trace = f.read()‘, I printed
the content of 'trace', which was just as following:

Undefined   first referenced
 symbol in file
main/usr/lib/crt1.o
ld: fatal: symbol referencing errors. No output written to /tmp/tmpYN85Fm
collect2: ld returned 1 exit status

--
assignee: theller
components: ctypes
messages: 82303
nosy: kewang, theller
severity: normal
status: open
title: ctypes.util.find_library does not work under Solaris
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

[issue5290] subprocess.Popen.communicate does not encode unicode strings

[Beda Kosata]

New submission from Beda Kosata :

The method subprocess.Popen.communicate (more the underlying
_communicate) writes the input to the stdin stream without encoding,
regardless of it being a unicode string. The result is incorrect
behavior of the running program as it receives 4 bytes for each character.
As simple text program is here:

import subprocess
from base64 import b16encode

command = ["cat"]
p = subprocess.Popen(command, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
data = u"test text"
o, er = p.communicate(data)
print b16encode(o)

I believe that this issue is closely related to Issue2683 where this was
fixed for Python 3.0.

--
components: Library (Lib)
messages: 82304
nosy: beda
severity: normal
status: open
title: subprocess.Popen.communicate does not encode unicode strings
type: behavior
versions: Python 2.5

___
Python tracker 

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

[issue5291] Windows upgrade to 2.6.1 requires 2.6 installer to be present

[Michael Kesper]

New submission from Michael Kesper :

When upgrading to 2.6.1, an error occurs if the old installer is not
found. I needed to open it several times until I read _what_ was needed.
Finding old installers on python.org requires too much search, too.

--
components: Installation
files: python_261.png
messages: 82305
nosy: mkesper
severity: normal
status: open
title: Windows upgrade to 2.6.1 requires 2.6 installer to be present
versions: Python 2.6
Added file: http://bugs.python.org/file13114/python_261.png

___
Python tracker 

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

[issue5284] platform.linux_distribution() improperly documented

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 2009-02-16 22:42, Armin Ronacher wrote:
> New submission from Armin Ronacher :
> 
> platform.linux_distribution() was added in 2.6 as an alias for
> platform.dist().  However the documentation lists platform.dist() as an
> alias for platform.linux_distribution() and there is no information that
> the latter appered in 2.6 whereas the former exists since 2.4 I think.

> Not sure what the fix is, but it should be documented properly with "..
> versionadded:: 2.6".

Note that dist() redirects to linux_distribution(), not the other
way around.

I'll add the versionadded tags and also clarify the dist() documentation:
it's missing a comment that full_distribution_name is set to false
when redirecting to linux_distribution().

___
Python tracker 

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

[issue5292] mmap crashes just on boundary.

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto :

I noticed following code crashes. I'll post fix soon.

import mmap
import os

def main():
align = mmap.ALLOCATIONGRANULARITY
path = os.path.splitext(__file__)[0] + ".txt"
with open(path, "w") as f:
f.write("0" * align)
f.write("1" * align)
f.write("2" * align)
with open(path, "r+") as f:
m = mmap.mmap(f.fileno(), align)
m[align] # crash
m[align] = '1' # crash too

if __name__ == '__main__':
main()

--
components: Extension Modules
messages: 82307
nosy: ocean-city
severity: normal
status: open
title: mmap crashes just on boundary.
type: crash
versions: 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

[issue2279] distutils sdist add_defaults does not add data_files

[Tarek Ziadé]

Tarek Ziadé  added the comment:

added in r69710. Thx

___
Python tracker 

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

[issue5292] mmap crashes just on boundary.

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Here is a patch.

--
keywords: +patch
Added file: http://bugs.python.org/file13115/fix_segfault_on_boundary.patch

___
Python tracker 

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

[issue5287] logging package on IronPython

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Rather than explicit testing for sys.platform, a try...except would be
more flexible and more future-proof.

--
nosy: +pitrou

___
Python tracker 

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

[issue5293] socket timeouts even in blocking mode

[anatoly techtonik]

New submission from anatoly techtonik :

The code below exits with timeout after about 20 secs on Windows +
Python 2.5.4

import socket
# address of server routable, but offline
server = "192.168.1.2"
s = socket.socket()
s.setblocking(1)
s.connect((server, 139))
s.close()

The output is:

Traceback (most recent call last):
  File "D:\.env\test.py", line 6, in 
s.connect((server, 139))
  File "", line 1, in connect
socket.error: (10060, 'Operation timed out')

If timeout is set to 1 it exits almost immediately. If timeout is large
it waits for about 20 seconds and exits.

I use socket to wait for the network service to appear. The target
machine 192.168.1.2 belongs to local network, but offline.

--
components: Library (Lib), Windows
messages: 82311
nosy: techtonik
severity: normal
status: open
title: socket timeouts even in blocking mode
versions: Python 2.5

___
Python tracker 

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

[issue5287] logging package on IronPython

[STINNER Victor]

STINNER Victor  added the comment:

> IronPython provides sys._getframe but it throws an exception 
> if you call it with a non-zero depth.

Stupid question: why not fixing sys._getframe()?

--
nosy: +haypo

___
Python tracker 

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

[issue2279] distutils sdist add_defaults does not add data_files

[Tarek Ziadé]

Tarek Ziadé  added the comment:

2009/2/17 George Sakkis :
>> Maybe that could be a new feature ?
>
> That would be nice, especially if we want to reimplement MANIFEST.in as
> setup() option at some point. My current implementation doesn't extend
> the API, so there's no way to specify a subset of files under a
> directory like recursive-include; every directory matched by a glob is
> copied in whole (recursively):

Please could you add a feature request ?

We will need to discuss it there.

>
> import os
> from distutils.command.build_py import build_py as _build_py
>
> class build_py(_build_py):
>def find_data_files(self, package, src_dir):
>files = []
>for p in _build_py.find_data_files(self, package, src_dir):
>if os.path.isdir(p):
>files.extend(os.path.join(par,f)
> for par,dirs,files in os.walk(p)
> for f in files)
>else:
>files.append(p)
>return files

> If it's a bug, it's certainly not accidental; there's a big XXX comment
> justifying this choice but I'm not convinced. I posted about it at
> http://mail.python.org/pipermail/python-list/2009-January/524263.html;
> if you think it's a bug I'll fill an issue.

Please do so, I am focusing on the Distutils-SIG ML , so I missed it

I don't know yet what is a proper way to adress this, but the bug tracker seem
apprioriate for this.

>
> --
> versions: +Python 2.6, Python 3.0
>
> ___
> Python tracker 
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/ziade.tarek%40gmail.com
>
>

___
Python tracker 

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

[issue5292] mmap crashes just on boundary.

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

This is obvious bug (and fix is obvious too), so I've commited in r69714.

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

[issue5287] logging package on IronPython

[Michael Foord]

Michael Foord  added the comment:

@Victor
IronPython doesn't use Python stack frames, so tracking them and then
constructing the objects on demand would add about a ~10% performance
hit to IronPython. Even when it is done it is likely to be an option
rather than on by default - using _getframe is usually a hack anyway. :-)

@Antoine
Could do that - it would have to trap ValueError. I'd be slightly
worried about it masking other bugs. In previous versions of logging
setting _srcfile to None was *the* mechanism for stopping the use of
_getframe.

___
Python tracker 

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

[issue5287] logging package on IronPython

[Michael Foord]

Michael Foord  added the comment:

Attached is an alternative patch that wraps the call to findCaller in a
try:...except.

Added file: http://bugs.python.org/file13116/logging2.patch

___
Python tracker 

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

[issue5289] ctypes.util.find_library does not work under Solaris

[Ke Wang]

Ke Wang  added the comment:

I tested the command 'gcc -Wl,-t' on Ubuntu, it works fine.
But on Solaris, it doesn't work as expected.

Finally I find that gcc does not use GNU ld on Solaris, instead, it uses
SUN ld.

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

Antoine, were your posted results on a 64-bit or a 32-bit system?

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Mark, I think it was 32-bit at the time.

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Now with the latest patch, and under a 64-bit system (the same one
actually, but with a 64-bit distro):

* pybench is roughly 2% slower 
* timeit -s "a=1;b=77" "a//b"
- before: 0.563 usec per loop
- after: 0.226 usec per loop
* timeit -s "a=1;b=77" "a*b"
- before: 0.179 usec per loop
- after: 0.131 usec per loop
* timeit -s "a=1;b=77" "a+b"
- before: 0.174 usec per loop
- after: 0.134 usec per loop

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Actually, I think my previous results were in 64-bit mode already.

By the way, I don't think unconditionally using uint64_t is a good thing
on 32-bit CPUs. uint64_t might be an emulated type, and operations will
then be very slow.
It would be better to switch based on sizeof(long) (for LP64 systems) or
sizeof(void *) (for LLP64 systems).

___
Python tracker 

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

[issue5294] pdb "break" command messes up "continue"

[Petr Viktorin]

New submission from Petr Viktorin :

Consider this program:

import pdb

pdb.set_trace()

print ("At line 5")
print ("At line 6")
print ("At line 7")
print ("At line 8")
print ("At line 9")

When set_trace starts the debugger, I set a breakpoint at line 8. When I
do that, the continue command starts single-stepping instead of what it
usually does.
Also, the module will appear twice on the call stack (although pdb won't
show this).

Here is the pdb session:

$ python pdbfail.py
> /home/petr/tmp/pdbfail.py(5)()
-> print ("At line 5")
(Pdb) break 8
Breakpoint 1 at /home/petr/tmp/pdbfail.py:8
(Pdb) continue
At line 5
> /home/petr/tmp/pdbfail.py(6)()
-> print ("At line 6")
(Pdb) continue
At line 6
> /home/petr/tmp/pdbfail.py(7)()
-> print ("At line 7")
(Pdb) where
> /home/petr/tmp/pdbfail.py(7)()
-> print ("At line 7")
(Pdb) quit
Traceback (most recent call last):
  File "pdbfail.py", line 7, in 
print ("At line 7")
  File "pdbfail.py", line 7, in 
print ("At line 7")
  File "/usr/lib/python2.5/bdb.py", line 48, in trace_dispatch
return self.dispatch_line(frame)
  File "/usr/lib/python2.5/bdb.py", line 67, in dispatch_line
if self.quitting: raise BdbQuit
bdb.BdbQuit

--
components: Library (Lib)
messages: 82322
nosy: En-Cu-Kou
severity: normal
status: open
title: pdb "break" command messes up "continue"
versions: Python 2.6, Python 3.0

___
Python tracker 

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

[issue5282] mmap.resize and offset

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Here is a patch.

--
keywords: +patch
Added file: http://bugs.python.org/file13117/fix_offset_and_resize.patch

___
Python tracker 

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

[issue5294] pdb "break" command messes up "continue"

[Petr Viktorin]

Petr Viktorin  added the comment:

It doesn't matter whether the breakpoint is set from within a function
or not, but only the module-level frame is affected.

import pdb

def test():
print ("At line 4")
print ("At line 5")
print ("At line 6")
print ("At line 7")

pdb.set_trace()

print ("At line 11")
print ("At line 12")
test()
print ("At line 13")
print ("At line 14")

$ python pdbfail.py
> /home/petr/tmp/pdbfail.py(11)()
-> print ("At line 11")

...[single-step to line 4]...

> /home/petr/tmp/pdbfail.py(4)test()
-> print ("At line 4")
(Pdb) b 14
Breakpoint 1 at /home/petr/tmp/pdbfail.py:14
(Pdb) c
At line 4
At line 5
At line 6
At line 7
> /home/petr/tmp/pdbfail.py(14)()
-> print ("At line 13")
(Pdb) c
At line 13
> /home/petr/tmp/pdbfail.py(15)()
-> print ("At line 14")
(Pdb) c
At line 14
--Return--
> /home/petr/tmp/pdbfail.py(15)()->None
-> print ("At line 14")
(Pdb) c

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Actually, I still get a speedup on a 32-bit build. :)

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's a version of the patch that includes optimizations to
basecase multiplication, and a streamlined x_divrem for faster division.
 With Victor's benchmark, I'm getting 43% speed increase on 64-bit
Linux/Core 2 Duo.

Note: the base patch is stable and ready for review;  in contrast, the
optimizations are still in a state of flux, so the +optimizations
patch is just there as an example of what might be possible.

About using uint64_t:

the 64-bit type isn't really used very much:  its main role is as the
result type of a 32-bit by 32-bit multiplication.  So it might
not matter too much if it's an emulated type;  what's
important is that the 32-bit by 32-bit multiply with 64-bit results
is done in a single CPU instruction.  I don't know how to test for
this.  Do you know of a mainstream system where this isn't true?

I'll test this tonight on 32-bit PPC and 32=bit Intel, and report back.

I don't care very much about trying to *automatically* do the right
thing for small or embedded systems:  they can use the
--disable-big-digits configure option to turn 30-bit digits off.

Antoine, do you think we should be using 30-bit digits by default *only*
on 64-bit machines?  I guess I could go with that, if it
can be manually overridden by the configure option.

Added file: 
http://bugs.python.org/file13118/30bit_longdigit13+optimizations.patch

___
Python tracker 

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

[issue706585] Expose FinderInfo in FSCatalogInfo

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I'm closing this as "wont fix" because the Carbon bindings are deprecated 
and are removed in Python 3.0.

--
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue706592] Crbon.File.FSSpec should accept non-existing pathnames

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Closing as "won't fix" because the Carbon bindings are deprecated, and 
FSSpec's are even more deprecated (they're even deprecated at the C-level)

--
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Changes by Mark Dickinson :


Removed file: http://bugs.python.org/file11986/30bit_longdigit6.patch

___
Python tracker 

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

[issue806149] aetools.TalkTo methods can be obscured

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Closing as "won't fix" because the aepack module is deprecated and has 
various other major issues on little-endian systems.

--
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue852150] Can't send Apple Events without WindowServer connection

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Closing as won't fix because the Carbon modules are deprecated. 

This doesn't actually affect behaviour of the Carbon bindings, other than 
causing an icon to appear on the dock which is basicly purely cosmetical.

--
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue853656] Carbon.CF.CFURLRef should be easier to create

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Carbon.CF is very imcomplete. Use PyObjC instead.

--
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue869649] Quicktime missing funcitonality

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Fixing this isn't worth the trouble.

--
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue878560] Add a console window for Carbon MacPython applets

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Closing as won't fix. The "Make Applet" tool is still present, but rather 
useless.

Use py2app to create application bundles.

--
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue5284] platform.linux_distribution() improperly documented

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Fixed in r69717.

--
versions:  -Python 2.4, Python 2.5, Python 2.6, 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

[issue5284] platform.linux_distribution() improperly documented

[Marc-Andre Lemburg]

Changes by Marc-Andre Lemburg :


--
status: open -> closed

___
Python tracker 

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

[issue2733] mmap resize fails on anonymous memory (Windows)

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Tim, I confirmed your test fails on my machine, and is fixed by your patch.
I want to commit this. Can I?

--
components: +Extension Modules, Windows -Library (Lib)
nosy: +ocean-city
stage:  -> commit review
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

___
Python tracker 

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

[issue2733] mmap resize fails on anonymous memory (Windows)

[Tim Golden]

Tim Golden  added the comment:

>From me, yes of course, but I assume you want another
core dev for a 2nd opinion.

___
Python tracker 

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

[issue5282] mmap.resize and offset

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

I hope this is obvious too. Fixed in r69718.

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

[issue1759169] clean up Solaris port and allow C99 extension modules

[John Levon]

John Levon  added the comment:

> However, experience tells that systems can break in surprising ways
> if the system headers are compiled with different defines.

This is indeed a reasonable concern (for which the best solution is
dropping the defines in the Python compile).

> I do feel this restrictiveness of the header files (wrt. C99) is
> arbitrary, and has no use.

Unfortunately, neither you, I, nor Sun can do anything at all about this
fact. I've filed an RFE for you:

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6806390
feature_tests.h could be laxer about C99

(It'll take a while to be visible externally.)

Even if this happens, though, it's strictly a workaround: it is still a
bug that Python sets these defines on Solaris: they do not mean what the
Python build thinks they mean. It's effectively a Linux-ism.

> setting _XOPEN_SOURCE had worked fine since Solaris 7.

The particular change we're talking about (C99) went back in 2003:

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4760794
4760794 UNIX03: sys/feature_tests.h updates required to support SUSv3
and c99

so Python has been broken by this for all of the Solaris 10 lifecycle.

___
Python tracker 

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

[issue3921] smtplib cannot sendmail over TLS

[Musashi Tamura]

Musashi Tamura  added the comment:

The difference is this line.

(2.5, work)
send: 'AUTH PLAIN AGxhbWJkYS5sZXRAZ21haWwuY29tAGNoaWtha29zMDA=\r\n'

(Python3, error)
send: 'AUTH PLAIN AGxhbWJkYS5sZXRAZ21haWwuY29tAGNoaWtha29zMDA=\n\r\n'

--
nosy: +miwa

___
Python tracker 

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

[issue974159] Starting a script in OSX within a specific folder

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
assignee:  -> ronaldoussoren
nosy: +ronaldoussoren

___
Python tracker 

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

[issue1941] 2.6 stdlib using with statement

[Jean-Paul Calderone]

Changes by Jean-Paul Calderone :


--
nosy:  -exarkun

___
Python tracker 

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

[issue1047540] Turtle.py hangs Idle

[Daniel Diniz]

Daniel Diniz  added the comment:

Taro, the OP, has been able to reproduce the issue with Python 3.0.
Leaving open, details on how to reproduce forthcoming.

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

[issue5295] turtle.py "dicionary" spelling patch

[David W. Lambert]

New submission from David W. Lambert :

x/lib/python3.0$ diff --unified turtle.py.bak turtle.py
--- turtle.py.bak   2009-02-17 11:29:15.0 -0500
+++ turtle.py   2009-02-17 11:29:37.0 -0500
@@ -2265,7 +2265,7 @@
"outline":   positive number
"tilt"   :   number
 
-This dicionary can be used as argument for a subsequent
+This dictionary can be used as argument for a subsequent
 pen()-call to restore the former pen-state. Moreover one
 or more of these attributes can be provided as keyword-arguments.
 This can be used to set several pen attributes in one statement.

--
components: Library (Lib)
messages: 82341
nosy: LambertDW
severity: normal
status: open
title: turtle.py "dicionary" spelling patch
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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

As I said, I actually see a speedup as well on a 32-bit build on a
64-bit CPU. So the current patch (30bit_longdigit13.patch) is fine.

___
Python tracker 

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

[issue1159425] 2.4 crashes when try to exit app and mulitple threads active

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

the issue1596321 is very similar (same traceback on another platform).
The problem is still valid, and the discussion seems more advanced there.

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

[issue1159425] 2.4 crashes when try to exit app and mulitple threads active

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
superseder:  -> KeyError at exit after 'import threading' in other thread

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Some more benchmarks results (with 30bit_longdigit13.patch):

* Victor's bench_int.py:
- 32-bit without patch: 1370.1 ms
- 32-bit with patch:1197.8 ms (23% speedup)
- 64-bit without patch: 1357.6 ms
- 64-bit with patch:981.6 ms  (28% speedup)

* calculating 2000 digits of pi (*):
- 32-bit without patch: 2.87 s.
- 32-bit with patch:2.87 s. (0% speedup: ???)
- 64-bit without patch: 3.35 s. 
- 64-bit with patch:1.68 s. (50% speedup)


(*) using the following script adapted for py3k:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=pidigits&lang=python&id=1

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Changes by Antoine Pitrou :


___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here's the py3k version of pidigits.py.

Added file: http://bugs.python.org/file13119/pidigits.py

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks, Antoine.  I've reworked the configure stuff anyway:  the decision
about what size digits to use should take place in pyport.h rather than 
Include/longintrepr.h.  Updated patches will arrive shortly!

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

Updated non-optimized patch.  The only real change is that I've moved 
some of the configuration stuff around (so not worth re-benchmarking 
this one);  I hope that I've now got the division of labour correct:

- configure script simply parses the --enable-big-digits option and sets
  PYLONG_DIGIT_SIZE in pyconfig.h to 15 or 30, or leaves it undefined
  if that option wasn't given to configure

- PC/pyconfig.h doesn't define PYLONG_DIGIT_SIZE

- pyport.h chooses a suitable value for PYLONG_DIGIT_SIZE if it's not
  already defined

- Include/longintrepr.h just follows orders: it expects 
PYLONG_DIGIT_SIZE
  to be defined already, and complains if PYLONG_DIGIT_SIZE=30 but the
  necessary integer types aren't available.

Thanks for all the benchmarking.

I'd probably better check on python-dev before pushing this in, since 
it's a new feature.  I hope no-one wants a PEP. :-)

Added file: http://bugs.python.org/file13120/30bit_longdigit14.patch

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The last patch (30bit_longdigit14.patch) is obviously missing some
stuff, but other than that I think everything's fine and you could commit.

___
Python tracker 

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

[issue5287] logging package on IronPython

[Vinay Sajip]

Vinay Sajip  added the comment:

Fix checked into release26-maint.

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

Oops.  Here's the correct patch.

Added file: http://bugs.python.org/file13121/30bit_longdigit14.patch

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Changes by Mark Dickinson :


Removed file: http://bugs.python.org/file13120/30bit_longdigit14.patch

___
Python tracker 

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

[issue5287] logging package on IronPython

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Vinay, the fix should also be committed to trunk (unless the relevant
code doesn't exist anymore), and to py3k.

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Changes by Mark Dickinson :


Added file: http://bugs.python.org/file13122/30bit_longdigit14.patch

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Changes by Mark Dickinson :


Removed file: http://bugs.python.org/file13121/30bit_longdigit14.patch

___
Python tracker 

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

[issue5291] Windows upgrade to 2.6.1 requires 2.6 installer to be present

[Martin v. Löwis]

Martin v. Löwis  added the comment:

How exactly did you install the old installer? It should have been
cached into your Windows folder, so that it is available on uninstallation.

That the old installer is required on an upgrade installation in
unavoidable; installation of 2.6.1 essentially uninstalls 2.6 first,
then installs 2.6.1 - the uninstallation requires the old installer.

--
nosy: +loewis

___
Python tracker 

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

[issue5293] socket timeouts even in blocking mode

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Why do you think this is a bug in Python?

--
nosy: +loewis

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Jeffrey Yasskin]

Changes by Jeffrey Yasskin :


--
nosy: +collinwinter, jyasskin

___
Python tracker 

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

[issue5283] setting __class__ in __del__ is bad. mmkay. negative ref count! kaboom!

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Yes, the wrong type is DECREF'd when the object is deallocated.
Patch attached.

--
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file13123/del_changes_class.patch

___
Python tracker 

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

[issue5293] socket timeouts even in blocking mode

[anatoly techtonik]

anatoly techtonik  added the comment:

Because documentation doesn't say that Python should timeout after 20
seconds after entering blocking mode if socket to remote host can not be
opened.

___
Python tracker 

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

[issue5293] socket timeouts even in blocking mode

[Gregory P. Smith]

Gregory P. Smith  added the comment:

You can't use a connect() call for the purpose of waiting for your 
network to be up.  This has nothing to do with Python.  This is how all 
network APIs work regardless of OS and language.

The "timeout" is due to the network stack being unable to find the 
remote host (read up on ARP) and eventually returning an error.  You 
need to deal with that in your own code.

--
nosy: +gregory.p.smith
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

[issue5296] Use of term sequence in Reference 6.3 Assignment Statements

[bob gailer]

New submission from bob gailer :

Currently reads, in part, "If the target list is a comma-separated list
of targets: The object must be a sequence ..."

Change "a sequence" to "an iterable".

Also consider removing references to versions earlier than 1.5.

--
assignee: georg.brandl
components: Documentation
messages: 82357
nosy: bgailer, georg.brandl
severity: normal
status: open
title: Use of term sequence in Reference 6.3Assignment  Statements
type: behavior
versions: Python 2.5

___
Python tracker 

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

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

[Pavel Repin]

Pavel Repin  added the comment:

I'd like to point out that on some configurations (at least mine), you 
really need to specify /MANIFEST option to the linker, even though MSDN 
documentation seems to imply that /MANIFEST behavior is ON by default.
My config:
beta version of Windows 7
ActivePython 2.6.1.1
MSVS 2008 with 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 
for 80x86

--
keywords: +patch
nosy: +paxan
Added file: 
http://bugs.python.org/file13124/0001-Ensure-the-assembly-manifest-file-generation-is-gene.patch

___
Python tracker 

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

[issue1283110] Give __len__() advice for "don't know"

[Antoine Pitrou]

Antoine Pitrou  added the comment:

If iterators don't want their boolean value to be messed up, couldn't
they simply use __bool__ for that?

--
nosy: +pitrou

___
Python tracker 

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

[issue5192] Update log message formatting.

[Vinay Sajip]

Vinay Sajip  added the comment:

Isn't there a backward compatibility problem? If a message format string
contains both "%s" and "{0}", how is logging supposed to know what to
use - a % b or a.format(b)?

The way to do it is a custom Formatter, as you've indicated.

--
nosy: +vsajip
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Robert Schuppenies]

Changes by Robert Schuppenies :


--
nosy: +schuppenies

___
Python tracker 

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

[issue1283110] Give __len__() advice for "don't know"

[Benjamin Peterson]

Benjamin Peterson  added the comment:

On Tue, Feb 17, 2009 at 1:27 PM, Antoine Pitrou  wrote:
>
> Antoine Pitrou  added the comment:
>
> If iterators don't want their boolean value to be messed up, couldn't
> they simply use __bool__ for that?

Since there is no base iterator class, that would complicate the API
and lead to subtle bugs. Personally, I don't think any iterators
should supported len() at all.

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Has any conclusion been reached wrt. overhead of 30-bit multiplication
on 32-bit systems? IIUC, the single-digit multiplication is equivalent
to the C program

unsigned long long m(unsigned long long a, unsigned long b)
{
return a*b;
}

(i.e. one digit is cast into two digits, and multiplied with the other
one). gcc 4.3.3, on x86, compiles this into

movl12(%esp), %eax
movl8(%esp), %ecx
imull   %eax, %ecx
mull4(%esp)
leal(%ecx,%edx), %edx
ret

In pseudo-code, this is

tmp = high_a * b;
high_res:low_res = low_a * b;
high_res += tmp

So it does use two multiply instructions (plus an add), since one
argument got cast into 64 bits.

VS2008 compiles it into

pusheax
pushecx
push0
pushedx
call__allmu

i.e. it widens both arguments to 64 bits, then calls a library routine.

--
nosy: +loewis

___
Python tracker 

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

[issue5297] Bug in SocketServer Example

[Zach Dwiel]

New submission from Zach Dwiel :

There is a bug in the example code:
http://docs.python.org/library/socketserver.html

The very last example has the line:

print "Server loop running in thread:", t.getName()

should be:

print "Server loop running in thread:", server_thread.getName()

Should I post this somewhere else or is this the right place?

--
assignee: georg.brandl
components: Documentation
messages: 82363
nosy: georg.brandl, zdwiel
severity: normal
status: open
title: Bug in SocketServer Example
type: compile error

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

> unsigned long long m(unsigned long long a, unsigned long b)
> {
>return a*b;
> }

I think that's doing a 32 x 64 -> 64 multiplication;  what's being used is 
more like this:

unsigned long long m(unsigned long a, unsigned long b)
{
return (unsigned long long)a*b;
}

which gcc -O3 compiles to:

pushl   %ebp
movl%esp, %ebp
movl12(%ebp), %eax
mull8(%ebp)
leave
ret

___
Python tracker 

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

[issue5298] Inconsistency in C-API thread docs

[Philip Semanchuk]

New submission from Philip Semanchuk :

The language in the threading API documentation is a little
inconsistent. The section I'm talking about is here:
http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock

The GIL is variously referred to as "global lock", "interpreter lock",
"global interpreter lock", "GIL", and simply "the lock". Given the
infamy of the GIL, one might expect all of these to be equally clear.
But as someone coding to this API for the first time, I had plenty to
learn already and the need to ensure that all of these referred to the
same singleton was distracting.

This documentation begins, "The Python interpreter is not fully thread
safe. In order to support multi-threaded Python programs, there's a
global lock that must be held by the current thread before it can safely
access Python objects. Without the lock..."

My suggestion is to alter the second sentence to the following:
"Without this lock (called the global interpreter lock, or GIL for
short)"

All subsequent documentation references to "interpreter lock", "global
interpreter lock", and "lock" should be changed to "GIL". It would be
nice if the API referred to it consistently (e.g. PyEval_AcquireLock()
versus PyGILState_Ensure()) but that would require an interface change
which is obviously out of the question.

--
assignee: georg.brandl
components: Documentation
messages: 82365
nosy: georg.brandl, osvenskan
severity: normal
status: open
title: Inconsistency in C-API thread docs
versions: Python 2.4, 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

[issue5299] PyGILState_Ensure()/PyGILState_Release() documentation incomplete?

[Philip Semanchuk]

New submission from Philip Semanchuk :

The threading API documentation might omit out some important
information about the GIL. 

The GIL can be acquired by explicitly calling PyEval_AcquireLock(). One
can also acquire the GIL by calling PyGILState_Ensure(). The latter
differs from the former in that calling PyGILState_Ensure() when one
already has the GIL will not create deadlock. This is implied; it would
be helpful if this was explicitly stated. 

Likewise, I assume that the Nth call to PyGILState_Release() releases
the GIL, where N = the number of calls made previously to
PyGILState_Ensure(). But I don't know this and the documentation doesn't
make it clear. 

As a first-time user of the API, it makes me nervous to call
PyGILState_Ensure() which acquires the GIL without knowing for sure that
PyGILState_Release() releases it. I can't evaluate my code for logical
correctness, and when dealing with threads and the GIL, neither can I be
sure that timing-dependent bugs will show up in testing. As a result, my
code feels fragile.

I don't understand how the code works well enough to suggest better
documentation. If nothing else, it would be useful to see something that
promises that as long as each call to PyGILState_Ensure() is matched
with a call to PyGILState_Release(), the GIL will take care of itself.

--
assignee: georg.brandl
components: Documentation
messages: 82366
nosy: georg.brandl, osvenskan
severity: normal
status: open
title: PyGILState_Ensure()/PyGILState_Release() documentation incomplete?
versions: Python 2.4, 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

[issue5293] socket timeouts even in blocking mode

[Martin v. Löwis]

Martin v. Löwis  added the comment:

> Because documentation doesn't say that Python should timeout after 20
> seconds after entering blocking mode if socket to remote host can not be
> opened.

That's not true: The documentation says "In blocking mode, operations
block until complete." It takes 20 seconds for the connect attempt
to complete (with error 10060), therefore, you block 20s.

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

Patch uploaded to Rietveld (assuming that I did it right):

http://codereview.appspot.com/14105

___
Python tracker 

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

[issue776533] Carbon.Snd module SPB constructor shadowed

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I've reapplied the hack.

I'm closing the issue because we will not regenerate the Carbon bindings 
as these are deprecated and are no longer present in Python 3.x

--
nosy: +ronaldoussoren
resolution: later -> 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

[issue5293] socket timeouts even in blocking mode

[anatoly techtonik]

anatoly techtonik  added the comment:

After rewriting my reply several times I've noticed my mistake, but it
took more time to understand the problem than could be expected for a
language that we all would like to see as easy and intuitive as
possible. That why I still would like to see this bugreport reopened. At
first it seemed that adding missing details to documentation would be
enough, but now I see that this problem can be deeper.

The problem:
As far as I informed, the socket module is the only way to wait for
service on server:139 to appear. socket documentation doesn't reflect
that will happen if network server is down (server is not network adapter).

Analysis:
In this specific timeout condition when server is offline socket.connect
can throw two different errors: "socket.error: (10060, 'Operation timed
out')" and "socket.timeout: timed out"  Which one will fire and should
be catched depends on the visible timeout settings for the socket and on
invisible timeout value of underlying network library. Whichever occurs
first - wins. For example, this code will warn you about network timeout:

import socket
s = socket.socket()
s.settimeout(12.0)
try:
  s.connect(("192.168.1.2", 139))
except socket.timeout:
  print "connect timeout"

But this one won't:

import socket
s = socket.socket()
s.settimeout(120.0)
try:
  s.connect(("192.168.1.2", 139))
except socket.timeout:
  print "connect timeout"

So, for reliable socket programming you should catch both.

Solution:
If there is a possibility for a socket to timeout when it is not
expected then at least it should be documented. Alternative solution
would be to document and merge socket.error: 10060 into socket.timeout
exception.

___
Python tracker 

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

[issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't always result in NULL

[Robert Luce]

Robert Luce  added the comment:

Thomas, is there any chance of getting your attention for this one? 
Deciding whether or not this issue can be fully resolved by applying the
proposed patch would already be sufficient.  If it is not, I am willing
to invest more time on resolving this issue.

___
Python tracker 

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

[issue5300] Distutils ignores file permissions

[George Sakkis]

New submission from George Sakkis :

Distutils ignores file permissions when copying modules and package_data
files to the build directory, and consequently to the installation
directory too. According to an XXX comment at
distutils/command/build_py.py, this is deliberate so that the built
files are not read-only, which would be a nuisance when rebuilding. This
problem though could be solved by just setting the write flag for the
user (chmod u+w) instead of overwriting all the flags. In my case, some
executable files ceased to be executable after installation.

I believe that the default behavior should be changed to preserve all
permissions, with the possible exception of setting u+w. Even that might
be unnecessary; AFAIK to delete a file you need write permissions only
to its parent directory, not to the file itself.

Even if the current behavior is deemed correct, at the very least the
code should be refactored to allow easy overriding. Currently
build_module and build_package_data pass preserve_mode=False in their
body, so I had to copy and paste the whole methods just to set
preserve_mode=True.

--
assignee: tarek
components: Distutils
messages: 82372
nosy: gsakkis, tarek
severity: normal
status: open
title: Distutils ignores file permissions
type: behavior

___
Python tracker 

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

[issue5301] add mimetype for image/vnd.microsoft.icon (patch)

[Drew Hintz]

New submission from Drew Hintz :

Adds a mimetype entry for image/vnd.microsoft.icon

This mimetype is commonly used for favicon.ico files and is registered 
with IANA.

--
components: Library (Lib)
files: mimetypes.py.diff
keywords: patch
messages: 82373
nosy: adhintz
severity: normal
status: open
title: add mimetype for image/vnd.microsoft.icon (patch)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13125/mimetypes.py.diff

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

It looks as though Visual Studio 2008 does the 'right' thing, too, at 
least in some circumstances.  Here's some assembler output (MSVC Express 
Edition, 32-bit Windows XP / Macbook Pro).

; 3: unsigned long long mul(unsigned long x, unsigned long y) {

pushebp
mov ebp, esp

; 4: return (unsigned long long)x * y;

mov eax, DWORD PTR _x$[ebp]
mov ecx, DWORD PTR _y$[ebp]
mul ecx

; 5: }

pop ebp
ret 0

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor  added the comment:

> Patch uploaded to Rietveld (assuming that I did it right):
> http://codereview.appspot.com/14105

Hehe, your configure's patch is too huge for Rietveld which displays 
a "MemoryError" :-) Bug reported at:
http://code.google.com/p/rietveld/issues/detail?id=87

___
Python tracker 

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

[issue5293] socket timeouts even in blocking mode

[Martin v. Löwis]

Martin v. Löwis  added the comment:

10060 is a winsock error, and there are many, MANY more of them. Read
the winsock documentation for details. It's both impossible and
pointless to document them, since some never occur, others aren't
documented by Microsoft well enough in the first place. Many aspects of
the Microsoft TCP stack are also fairly obscure, and can also change
across Windows releases.

___
Python tracker 

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

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 2009-02-17 20:22, Pavel Repin wrote:
> Pavel Repin  added the comment:
> 
> I'd like to point out that on some configurations (at least mine), you 
> really need to specify /MANIFEST option to the linker, even though MSDN 
> documentation seems to imply that /MANIFEST behavior is ON by default.
> My config:
> beta version of Windows 7
> ActivePython 2.6.1.1
> MSVS 2008 with 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 
> for 80x86

Are you sure ?

We've had such a request before and the reason for MSVC not generating
a .manifest file was some setting the user had done on his system.

FWIW: distutils generates those files just fine for me.

Then again, it probably doesn't hurt just adding the option.

___
Python tracker 

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

[issue5302] Allow package_data globs match directories

[George Sakkis]

New submission from George Sakkis :

Currently each glob defined in package_data must match files only; if it
matches a directory, it raises an exception later when calling
copy_file(). This means that a glob like 'mydata/*' will fail if there
is any subdirectory under 'mydata'. One simple useful change would be to
allow a glob match a directory and interpret it as a recursive inclusion
of the directory.

A more general feature request (perhaps a separate ticket) would be to
port to setup() the logic currently expressed in MANIFEST.in. In the
long term, MF.in should IMO be deprecated because (a) it's a second file
one has to remember to write and maintain in addition to setup.py (b)
has its own ad-hoc syntax instead of python and (c) overlaps in scope
with package_data and data_files of setup.py. The exact API exposing
MF.in's functionality can be decided after (and if) there is consensus
on deprecating/replacing it.

--
assignee: tarek
components: Distutils
messages: 82378
nosy: gsakkis, tarek
severity: normal
status: open
title: Allow package_data globs match directories
type: feature request

___
Python tracker 

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

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

[Pavel Repin]

Pavel Repin  added the comment:

Hi Marc,I am pretty sure it helped on my particular configuration.
I was trying to compile MySQL-python-1.2.2.tar.gz package from source and it
was failing in mt.exe step because the manifest file was not there.
I didn't do anything special on my machine. I have 3 versions of MSVS
installed cleanly side-by-side (which is a legit scenario): MSVS 2003, MSVS
2005, and MSVS 2008. All at the latest patch levels. No standalone
PlatformSDKs are installed.

Besides, if you just ignore the obscure blurb about /MANIFEST option being
default in MSDN, and read the descriptions of both /MANIFEST and
/MANIFESTFILE options, you would agree that it will not do any harm to be
explicit and always have /MANIFEST option passed to linker.

I'm going to do one more experiment with a different machine, this time it
will be Vista (not W7) with a similar MSVS setup. I will report my findings.

On Tue, Feb 17, 2009 at 2:08 PM, Marc-Andre Lemburg
wrote:

>
> Marc-Andre Lemburg  added the comment:
>
> On 2009-02-17 20:22, Pavel Repin wrote:
> > Pavel Repin >
> added the comment:
> >
> > I'd like to point out that on some configurations (at least mine), you
> > really need to specify /MANIFEST option to the linker, even though MSDN
> > documentation seems to imply that /MANIFEST behavior is ON by default.
> > My config:
> > beta version of Windows 7
> > ActivePython 2.6.1.1
> > MSVS 2008 with 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
> > for 80x86
>
> Are you sure ?
>
> We've had such a request before and the reason for MSVC not generating
> a .manifest file was some setting the user had done on his system.
>
> FWIW: distutils generates those files just fine for me.
>
> Then again, it probably doesn't hurt just adding the option.
>
> ___
> Python tracker 
> 
> ___
>

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

___
Python tracker 

___Hi Marc,I am pretty sure it helped on my 
particular configuration.I was trying to compile 
MySQL-python-1.2.2.tar.gz package from source and it was failing in mt.exe step 
because the manifest file was not there.



I didn't do anything special on my machine. I have 3 versions of MSVS 
installed cleanly side-by-side (which is a legit scenario): MSVS 2003, MSVS 
2005, and MSVS 2008. All at the latest patch levels. No standalone PlatformSDKs 
are installed.



Besides, if you just ignore the obscure blurb about 
/MANIFEST option being default in MSDN, and read the descriptions of both 
/MANIFEST and /MANIFESTFILE options, you would agree that it will not do any 
harm to be explicit and always have /MANIFEST option passed to linker.



I'm going to do one more experiment with a different 
machine, this time it will be Vista (not W7) with a similar MSVS setup. I will 
report my findings.
On Tue, Feb 17, 2009 at 2:08 PM, Marc-Andre Lemburg 
rep...@bugs.python.org> wrote:

Marc-Andre Lemburg m...@egenix.com> added the comment:

On 2009-02-17 20:22, Pavel Repin wrote:
> Pavel Repin prepin+pythonb...@gmail.com> added the comment:
>
> I'd like to point out that on some configurations (at least mine), 
you
> really need to specify /MANIFEST option to the linker, even though MSDN
> documentation seems to imply that /MANIFEST behavior is ON by default.
> My config:
> beta version of Windows 7
> ActivePython 2.6.1.1
> MSVS 2008 with 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
> for 80x86

Are you sure ?

We've had such a request before and the reason for MSVC not generating
a .manifest file was some setting the user had done on his system.

FWIW: distutils generates those files just fine for me.

Then again, it probably doesn't hurt just adding the option.

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue4431>
___

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

[issue1054967] bdist_deb - Debian packager

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Sean,

I am re-opening this issue, to study the inclusion of a bdist_deb
command for 2.7/3.1, since there's some interest in the community.

I have taken the assigment since it was rejected, but let me know if you
want me to assign back to you of course.

--
assignee: jafo -> tarek
nosy: +tarek
resolution: rejected -> 
status: closed -> open
versions: +Python 2.7, Python 3.1 -Python 2.5

___
Python tracker 

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

[issue5303] Use base 2**30 for Python longs, when possible

[Martin v. Löwis]

New submission from Martin v. Löwis :

http://codereview.appspot.com/14105/diff/1/11
File Doc/library/sys.rst (right):

http://codereview.appspot.com/14105/diff/1/11#newcode418
Line 418: A struct sequence that holds information about Python's
I don't think the sequence interface is really important here. There
should be a way to easily define regular struct-like classes (with no
sequence interface). Perhaps structseq could be modified to drop
sequence interface, and new structseqs should turn it off usually.

http://codereview.appspot.com/14105/diff/1/6
File Include/longintrepr.h (right):

http://codereview.appspot.com/14105/diff/1/6#newcode24
Line 24: Furthermore, NSMALLNEGINTS and NSMALLPOSINTS should fit in a
digit. */
Merge the comments into a single on. There is no need to preserve the
evolution of the code in the comment structure.

http://codereview.appspot.com/14105/diff/1/9
File Objects/longobject.c (right):

http://codereview.appspot.com/14105/diff/1/9#newcode2872
Line 2872: /* XXX benchmark this! Is is worth keeping? */
Why not PyLong_FromLongLong if available (no special case if not)?

http://codereview.appspot.com/14105/diff/1/10
File PC/pyconfig.h (right):

http://codereview.appspot.com/14105/diff/1/10#newcode318
Line 318: #define PY_UINT64_T unsigned __int64
I think this should use PY_LONG_LONG, to support MingW32; likewise,
__int32 shouldn't be used, as it is MSC specific

http://codereview.appspot.com/14105/diff/1/2
File Python/marshal.c (right):

http://codereview.appspot.com/14105/diff/1/2#newcode160
Line 160: w_long((long)(Py_SIZE(ob) > 0 ? l : -l), p);
This needs to deal with overflow (sizeof(size_t) > sizeof(long))

http://codereview.appspot.com/14105/diff/1/2#newcode540
Line 540: if (n < -INT_MAX || n > INT_MAX)
I think this is obsolete now; longs can have up to ssize_t_max digits.

http://codereview.appspot.com/14105/diff/1/8
File configure.in (right):

http://codereview.appspot.com/14105/diff/1/8#newcode3132
Line 3132: # determine what size digit to use for Python's longs
I'm skeptical (-0) that we really need to have such a configure option.

http://codereview.appspot.com/14105/diff/1/14
File pyconfig.h.in (left):

http://codereview.appspot.com/14105/diff/1/14#oldcode9
Line 9: #undef AC_APPLE_UNIVERSAL_BUILD
We should find out why this is gone.

http://codereview.appspot.com/14105/diff/1/14#oldcode958
Line 958: /* Enable extensions on AIX 3, Interix.  */
Likewise, this needs to be preserved.

http://codereview.appspot.com/14105/diff/1/14#oldcode1017
Line 1017: /* Define WORDS_BIGENDIAN to 1 if your processor stores words
with the most
This also needs to be preserved.

http://codereview.appspot.com/14105

--
messages: 82381
nosy: loewis, marketdickinson
severity: normal
status: open
title: Use base 2**30 for Python longs, when possible

___
Python tracker 

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

[issue5303] Use base 2**30 for Python longs, when possible

[Martin v. Löwis]

Martin v. Löwis  added the comment:

This was meant to go to issue4258, but I failed to set the subject when
sending this from Rietveld.

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

[issue2279] distutils sdist add_defaults does not add data_files

[George Sakkis]

George Sakkis  added the comment:

Opened #5300 and #5302 for the mentioned issues. 

Btw in your patch, I believe `os.path.join(dirname, f)` should be
replaced by `f` alone; `dirname` refers to the dir under the
installation directory, not the source.

___
Python tracker 

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

[issue5302] Allow package_data globs match directories

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I am no in favor of MANIFEST.in removal because I find it very
convenient to define what is included in a package  and I rarely use
package_data or data_files. So I am -1 on its deprecation.

That said, having a mechanism to include directory recursively sounds
good. And people using this wouldn't have to maintain a MANIFEST.in.

Overall, I don't see a problem of having both ways.

Maybe some kind of plugin system could be created so people can
implement their own way to get a file list. I am thinking here about
the feature in setuptools that builds the file list using .svn,
so you don't have to define anything at all.

In any case, for the glob in data_files, how do you express this
MANIFEST.in line ?

recursive-include directory/subdir *.py *.txt

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor  added the comment:

Ok, let's try 30bit_longdigit14.patch:

   patch -p0 < 30bit_longdigit14.patch
   autoconf && autoheader
   ./configure && make

I'm using two computers:

 - marge: Pentium4, 32 bits, 3 GHz (32 bits)
 - lisa: Core Quad (Q9300), 64 bits, 2.5 GHz (64 bits)

Both uses 32 bits digit (and 64 bits twodigits), py3k trunk and Linux.

* My bench_int.py:

  - 32-bit without patch: 1670.7 ms
  - 32-bit with patch:1547.8 ms (+7.4%)
  - 64-bit without patch: 885.2 ms
  - 64-bit with patch:627.1 ms (+29.2%)

* pidigits 2000 (I removed the calls to print): 
  lowest result on 5 runs:

  - 32-bit without patch: 2991.5 ms
  - 32-bit with patch:3445.4 ms (-15.2%) SLOWER!
  - 64-bit without patch: 1949.9 ms
  - 64-bit with patch: 973.0 ms (+50.1%)

* pybench.py (minimum total)

  - 32-bit without patch: 9209 ms
  - 32-bit with patch:
  - 64-bit without patch: 4430 ms
  - 64-bit with patch:4330 ms (=)

pybench details:

Test32 bits (without,patch) | 64 bits (without,patch)
-
   CompareFloatsIntegers:  293ms  325ms |  113ms96ms
 CompareIntegers:  188ms  176ms |  129ms98ms
 DictWithIntegerKeys:  117ms  119ms |   73ms69ms
SimpleIntFloatArithmetic:  192ms  204ms |   84ms80ms
 SimpleIntegerArithmetic:  188ms  196ms |   84ms80ms
-

On 64 bits, all integer related tests are faster. On 32 bits, some
tests are slower.

Sum up: on 64 bits, your patch is between cool (30%) and awesome 
(50%) :-) On 32 bits, it's not a good idea to use 32 bits digit 
because it's a little bit slower.

=> I would suggest to use 2^30 base only if sizeof(long)>=8 (64 bits 
CPU).

Note: I already get similar result (2^30 is slower on 32 bits CPU) in 
older tests.

___
Python tracker 

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor  added the comment:

New attachment: pidigits_noprint.py, hacked version of pidigits.py to 
remove the print and add the computation time in millisecond. Print 
was useless because we don't want to benchmark int->str conversion, 
especially when the integer is in [0; 9].

Added file: http://bugs.python.org/file13127/pidigits_noprint.py

___
Python tracker 

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

[issue5293] socket timeouts even in blocking mode

[anatoly techtonik]

anatoly techtonik  added the comment:

Isn't it a job of crossplatform programming language to abstract from
low-level platform details?

The scope of this bug is not about handling all possible Winsock errors.
It is about proper handling the sole timeout error from the list
http://www.winsock-error.com/ to make socket.connect() interface
consistent for both windows and linux.

In addition I believe that new socket.create_connection() function is
vulnerable to the same issue and its only a matter of time when somebody
reports that its additional "timeout" argument should be less than
mystic system network timeout value. That's why some sort of generalized
socket.connection_timeout exception is still needed.

BTW, I have tested the behaviour on linux - the system timeout on socket
does occur, but with different error code.

socket.error: (110, 'Connection timed out')

Note that the error message is different too. That means that to
properly wait for service to appear (or retry to reconnect later if
server is not available) you need to handle three error cases.

___
Python tracker 

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

[issue2279] distutils sdist add_defaults does not add data_files

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> Opened #5300 and #5302 for the mentioned issues. 

ok thanks

> Btw in your patch, I believe `os.path.join(dirname, f)` should be
> replaced by `f` alone; `dirname` refers to the dir under the
> installation directory, not the source.

Right, thanks George. I'v also added you in the ACKS for your contribution
on this (r69724)

___
Python tracker 

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

[issue5300] Distutils ignores file permissions

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> I believe that the default behavior should be changed to preserve 
> all permissions, with the possible exception of setting u+w. 
> Even that might be unnecessary; AFAIK to delete a file you need 
> write permissions only to its parent directory, not to the 
> file itself.

The u+w setting could also be done on the fly by copy_file at
installation time. e.g. when overwriting a read-only file.


> In my case, some 
>  executable files ceased to be executable after installation.

what is your use case of having executable file here ?

I'd use the 'scripts' metadata for that ?


> Even if the current behavior is deemed correct, at the very least 
> the code should be refactored to allow easy overriding.
> Currently build_module and build_package_data pass 
> preserve_mode=False in their
> body, so I had to copy and paste the whole methods 
> just to set preserve_mode=True.

But How do you handle the overwrite of a read-only file in your code then ?

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

[issue5293] socket timeouts even in blocking mode

[Martin v. Löwis]

Martin v. Löwis  added the comment:

> Isn't it a job of crossplatform programming language to abstract from
> low-level platform details?

It's certainly not Python's job. It's an explicit design goal, and a
long tradition, to expose system interfaces *as is*, with the very
same parameters, and the very same error codes. This is useful for
developers who need to understand what problem they encounter - they
can trust that Python doesn't second-guess the operating system.

It might be useful to put a layer on top of the system interfaces,
but such a layer needs to use different names.

> The scope of this bug is not about handling all possible Winsock errors.
> It is about proper handling the sole timeout error from the list
> http://www.winsock-error.com/ to make socket.connect() interface
> consistent for both windows and linux.

That's nearly impossible, with respect to specific error conditions.
The TCP stacks are too different.

You can easily define an common (but useless) error handling scheme
yourself: catch Exception, and interpret it as "it didn't work".

> BTW, I have tested the behaviour on linux - the system timeout on socket
> does occur, but with different error code.
> 
> socket.error: (110, 'Connection timed out')
> 
> Note that the error message is different too. That means that to
> properly wait for service to appear (or retry to reconnect later if
> server is not available) you need to handle three error cases.

That's correct. However, you shouldn't look at the error message when
handling the error on Linux. Instead, you should check whether the
error code is errno.ETIMEDOUT. The error message is only meant for
a human reader. Also notice that possible other errors returned from
connect are EACCES, EPERM, EADDRINUSE, EAFNOSUPPORT, EAGAIN,
EALREADY, EBADF, ECONNREFUSED, EFAULT, EINPROGRESS, EINTR, EISCONN,
ENETUNREACH, ENOTSOCK.

___
Python tracker 

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

[issue1229239] optionally allow mutable builtin types

[Greg Couch]

Greg Couch  added the comment:

FYI, I was able to work around this and use an unmodified Python by
subtyping type and overriding the setattr method as shown below.  It's a
lot messier than patching Python.

static int
Mutable_SetAttr(PyObject *obj, PyObject *name, PyObject *value)
{
// Can't just call PyObject_GenericSetAttr because
// we need to able to update the __str__ slot as well.
PyTypeObject *type = reinterpret_cast(obj);
type->tp_flags |= Py_TPFLAGS_HEAPTYPE;
int result = PyType_Type.tp_setattro(obj, name, value);
type->tp_flags &= ~Py_TPFLAGS_HEAPTYPE;
return result;
}

___
Python tracker 

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