[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Michael Wise]

Michael Wise  added the comment:

Dear Ronald

Not that simple. I had, for the first time, installed Python 2.6.3 via 
the .dmg rather than compiled from scratch, and then numpy, again via 
the .dmg. I was trying to compile biopython from scratch using disutils 
when the problem occurred. That was on a G4 PPC Mac laptop. On a 
different G5 PPC  PowerMac, I did the whole job from scratch and all was 
well.

I can confirm that get_platform was not the problem (check it 
specifically) and I got something to work by modifying the 
config/Makefile, but then worried about what else that would affect. I 
removed the .dmg supplied Python and numpy, and installed Python 2.6.3 
from scratch, but had problem of the disutils installation of numpy 
hanging, so I removed that and did the whole job based on the previous 
installation 2.5.2.

Cheers
MichaelW

Ronald Oussoren wrote:
> Ronald Oussoren  added the comment:
> 
> Michael: please file a new issue for this, your problem seems to be 
> unrelated to this one.
> 
> In that issue include information about:
> 
> 1) The python version you are using
> 2) The version of MacOSX
> 3) The version of Xcode (open /Developer/Applications/Xcode.app,
> check the version in the About dialog)
> 
> --
> 
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Ned Deily]

Ned Deily  added the comment:

>gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ...
>
>followed, unsurprisingly, by:
>gcc-4.0: installation problem, cannot exec
>'i686-apple-darwin8-gcc-4.0.0': No such file or directory

>From at least OS X 10.4 on, Xcode installs both variants of compilers so 
it is possible to build both Intel and PPC archs on any system.  I 
regularly build complete fat Python installers on a PPC G3 running 10.4.

$ uname -p
powerpc
$ i686-apple-darwin8-gcc-4.0.1 
i686-apple-darwin8-gcc-4.0.1: no input files

Was this possibly on an older version of OS X, say 10.3?  Otherwise, it 
sounds like that system did not have a complete installation of Xcode 
somehow.

--
nosy: +ned.deily

___
Python tracker 

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

[issue7060] test_multiprocessing dictionary changed size errors and hang

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Interesting.  I don't have a linux machine to debug this.  My patch 
appears harmless enough.  We are only storing an exception _object_, not 
any tracebacks or such.
If this were happening on my windows machine I would put in breakpoints 
where the ignored assertion is being raised and find out what's going on.

--

___
Python tracker 

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Michael Wise]

Michael Wise  added the comment:

Dear Ned

Odd you should say that. The system is the latest version of 10.4 
(10.4.11),  but I did notice that the compiler assumed 10.3. The version 
  of Xcode on this PowerBook G4 is 2.0 (quite old), so perhaps it has 
OSX 10.3 wired in. I don't think that was the issue, but to eliminate it 
I'll download Xcode when I'm at work on Monday (better bandwidth) and 
see if that does a better job.

Cheers (and thanks!)
Michael

Ned Deily wrote:
> Ned Deily  added the comment:
> 
>> gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ...
>>
>> followed, unsurprisingly, by:
>> gcc-4.0: installation problem, cannot exec
>> 'i686-apple-darwin8-gcc-4.0.0': No such file or directory
> 
>>From at least OS X 10.4 on, Xcode installs both variants of compilers so 
> it is possible to build both Intel and PPC archs on any system.  I 
> regularly build complete fat Python installers on a PPC G3 running 10.4.
> 
> $ uname -p
> powerpc
> $ i686-apple-darwin8-gcc-4.0.1 
> i686-apple-darwin8-gcc-4.0.1: no input files
> 
> Was this possibly on an older version of OS X, say 10.3?  Otherwise, it 
> sounds like that system did not have a complete installation of Xcode 
> somehow.
> 
> --
> nosy: +ned.deily
> 
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue7055] Automatic test___all__

[Nick Coghlan]

Nick Coghlan  added the comment:

I'm glad someone with more roundtuits than I had the same idea after the
logging error in 2.6.3 :)

The regrtest change isn't needed any more since RDM checked that concept
in separately - the test update itself looks fine though (and applies
and runs cleanly on the trunk).

--
nosy: +ncoghlan

___
Python tracker 

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

[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)

[Nick Coghlan]

Nick Coghlan  added the comment:

The thread safety problem comes from the fact that performing file IO as
mimetypes.init() does will release the GIL - if you want to ensure
thread safety in that context, you have to do your own locking.
mimetypes ignore this thread syncrhonisation problem completely with
unhelpful results.

An attempt was made to address the race condition in r72045 by
eliminating the infinite recursion. Instead, you just get init() being
invoked multiple times on different MimeTypes instances, with the last
one "winning" and being kept as the _db module global (which does
eliminate the crash, but has problems of its own).

This crash probably involves hitting the recursion limit and that's
always a bit dicey as to whether we actually manage to trap it before
the C stack goes boom. With this case being an infinite recursion in an
__init__() method leading to an infinite number of a given object type
being allocated, that's a bit special since it raises the prospect of
potentially running out of heap memory (although that's unlikely with
the default recursion limit unless there are an awful lot of threads
involved).

To check the simple failure mechnism, I tried threading out the following:

class Broken():
  def __init__(self):
break_it()

def break_it():
  Broken()

from threading import Thread
threads = [Thread(target=break_it) for x in range(100)]
for t in threads: t.start()

On my machine, the threads fail with "RuntimeError: maximum recursion
depth exceeded" for a recursion limit of 1000 or 1, but segfault at
100,000. However, the 100k recursion limit segfaults even if I only use
a single thread (i.e. call break_it() directly without involving the
threading module at all).

For the OP:

What value do you get for sys.getrecursionlimit()?
Do you still get the segfault if you use sys.setrecursionlimit() to
lower the maximum allowed level of recursion? (e.g. limit it to 200 or
500 recursions)

--
nosy: +ncoghlan

___
Python tracker 

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

[issue6626] show Python mimetypes module some love

[Nick Coghlan]

Nick Coghlan  added the comment:

Putting this here for the record rather than leaving it in Rietveld:

I appreciate the desire for a cleaner API for handling mimetypes, but
this isn't the way to get it. Finding projects that have their own
mimetypes implementations, asking them why they created their own rather
than using the standard one, seeing what features are common to those
APIs, etc, are all things that need to be done before making major
changes to the standard library API.

What you see as a critical bug (custom MimeTypes instances inheriting
their initial settings from the mimetypes._db instance), you can bet
some developers are relying on as a feature. If code is in the standard
library, someone, somewhere, is relying on it working just the way it is
now. Even bug fixes can sometimes break code that was designed to work
around the presence of the bug.

The concept of having a master copy that new instances are cloned from
isn't even particularly objectionable, so long as people clearly
understand that is what is going on (e.g. this happens with
decimal.DefaultContext being used as the basis for new decimal.Context
instances).

With code this old, 'softly, softly' is the way to go, and the fewer
user visible changes in semantics the better.

--

___
Python tracker 

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

[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)

[Leonardo Santagada]

Leonardo Santagada  added the comment:

I'm on os x 10.6 where threadboom.py doesn't segfault anymore at least
on the system provided python. The problem that I see is that it
shouldn't be segfaulting on mac os x 10.5 with the default recursion
limit (I think it is 1000) with 2 threads. IIRC in a simple recursive
function (not on object __init__ like you did) I could put 1 or more
as a recursion limit and still get a traceback, so I thought that 2
threads each with 1000 recursion limit should not be using the whole
stack. Also I think I did try to raise the stack limit with ulimit, but
I could be wrong.

Nick Coghlan, did you do your experments on os x 10.5? Can you try
threadboom.py on a python before the corrected mimetype lib landed
(somewhere between 2.6.2 and 2.6.3) or with an old version of the
mimetype lib?

I got the same errors both on my old white macbook core duo machine and
with a macbook pro core 2 duo and with both python 2.6.2 or 2.6.3 with
the old mimetypes lib.

I was worried with this bug because I guessed that maybe there is a race
condition of some sort on object creation on python 2.6. If someone can
reproduce the bug and understand the bug tell me it is a problem of
stack size I would rest my case and be happy with the segfault :).

ps: I will try to compile python2.6.2 here and reproduce the errors, if
I can I will reply with more info.

--

___
Python tracker 

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Michael: Again, please file a new issue for your problem because it is not 
related to this one.

I'm removing myself from the nosy-list for this bug.

--

___
Python tracker 

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

[issue6075] Patch for IDLE/OS X to work with Tk-Cocoa

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I have tried to apply the patches to python's trunk, but they don't apply 
cleanly at all.

Could you please rework the patches into a single larger patch that 
applies to the trunk.

--

___
Python tracker 

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

[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)

[Nick Coghlan]

Nick Coghlan  added the comment:

Knew I forgot to mention something - I'm not on OS X at all (Linux,
Ubuntu 8.04). I was only looking at this bug because RDM cross-linked it
to the mimetypes patch I was reviewing this evening.

Running the threadboom code, it passes fine for me on all of SVN head,
the 2.6 maintenance branch and the system Python (2.5.2).

I've added the OS X maintainer to the nosy list.

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue7097] urlparse.urljoin of simple "http://" and "somedomain.com" produces incorrect result

[steve steiner]

New submission from steve steiner :

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from urlparse import urljoin
>>> urljoin("http://";, "somedomain.com")
'http:///somedomain.com'

Note the three leading slashes, should be "http://somedomain.com";

--
components: Library (Lib)
messages: 93834
nosy: ssteiner
severity: normal
status: open
title: urlparse.urljoin of simple "http://"; and "somedomain.com" produces 
incorrect result
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

[issue7098] g formatting for decimal types should always strip trailing zeros.

[Mark Dickinson]

New submission from Mark Dickinson :

Type 'g' formatting for Decimal instances doesn't behave in the same way 
as for floats when an explicit precision is given.  It should strip all 
trailing zeros from the result:

Python 2.7a0 (trunk:75309, Oct 10 2009, 13:44:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> format(Decimal('123.00'), '.6g')  # expect '123'
'123.00'

(When no explicit precision is given, Decimal formatting with type 'g' 
tries to preserve the information about the exponent of the Decimal 
instance whenever possible;  this also differs from float formatting, but 
it's intentional.  This should probably be documented.)

--
assignee: mark.dickinson
components: Library (Lib)
messages: 93835
nosy: mark.dickinson
priority: normal
severity: normal
stage: test needed
status: open
title: g formatting for decimal types should always strip trailing zeros.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue7097] urlparse.urljoin of simple "http://" and "somedomain.com" produces incorrect result

[Brett Cannon]

Brett Cannon  added the comment:

urlparse.urljoin() is meant to join together a base URL with other URL 
parts. The protocol is part of the base URL and thus not supported by 
urlparse.urljoin().

--
nosy: +brett.cannon
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

[issue6075] Patch for IDLE/OS X to work with Tk-Cocoa

[Kevin Walzer]

Kevin Walzer  added the comment:

Single revised diff, "tkcocoa.diff", attached, applied against Python 
trunk. Have not tested against Python trunk, nor do I believe it solves 
the issue with the extra menu items appearing when a window is closed. But 
hopefully this will apply more cleanly.

--
Added file: http://bugs.python.org/file15096/tkcocoa.diff

___
Python tracker 

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

[issue7099] Decimal.is_normal should return True even for numbers with exponent > Emax

[Mark Dickinson]

New submission from Mark Dickinson :

Noticed by Stefan Krah:

Python 2.7a0 (trunk:75309, Oct 10 2009, 13:44:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> x = Decimal('9.e+1000')
>>> c = getcontext()
>>> c.prec = 9
>>> c.Emax = 999
>>> c.Emin = -999
>>> 
>>> x.is_normal()
False
>>> x.is_subnormal()
False
>>> x.is_infinite()
False
>>> x.is_nan()
False
>>> x.is_zero()
False

So if x isn't normal, subnormal, zero, nan or infinity, what the 
is it?!

x.is_normal() should probably be returning True here.

--
assignee: mark.dickinson
components: Library (Lib)
messages: 93838
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Decimal.is_normal should return True even for numbers with exponent > 
Emax
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue7098] g formatting for decimal types should always strip trailing zeros.

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's a patch for trunk.

--
keywords: +patch
nosy: +eric.smith
stage: test needed -> patch review
Added file: http://bugs.python.org/file15097/issue7098.patch

___
Python tracker 

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

[issue7098] g formatting for decimal types should always strip trailing zeros.

[Mark Dickinson]

Mark Dickinson  added the comment:

> It should strip all trailing zeros from the result:

Hmm.  Thinking about this some more, I don't think this is true:  format() 
shouldn't be throwing away significant information (in Decimal 
the number of trailing zeros *is* significant information) unless that's 
necessary to fit the result into the given precision.

So I think the current code is correct.

However, we could do with documenting the precise rules being used for 
Decimal formatting somewhere.

--

___
Python tracker 

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

[issue1625] bz2.BZ2File doesn't support multiple streams

[Antoine Pitrou]

Antoine Pitrou  added the comment:

As far as I can tell, the patch looks mostly good.
I just wonder, in Util_HandleBZStreamEnd(), why you don't set self->mode
to MODE_CLOSED if BZ2_bzReadOpen() fails.

As a sidenote, the bz2 module implementation seems to have changed quite
a bit between trunk and py3k, so if you want it to be backported to
trunk (2.7), you'll have to provide a separate patch.

--

___
Python tracker 

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

[issue7086] logging.handlers.SysLogHandler with TCP support

[Vinay Sajip]

Vinay Sajip  added the comment:

Fix checked into trunk and py3k.

--
resolution:  -> fixed
stage: test needed -> 
status: open -> closed

___
Python tracker 

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

[issue7100] test_xmlrpc: global name 'stop_serving' is not defined

[Antoine Pitrou]

New submission from Antoine Pitrou :

This happens at least on the py3k branch, I haven't checked other branches.


test test_xmlrpc failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
344, in tearDown
stop_serving()
NameError: global name 'stop_serving' is not defined

1 test failed:
test_xmlrpc
Unhandled exception in thread started by >
Error in sys.excepthook:
TypeError: 'NoneType' object is not callable

Original exception was:
Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
282, in _handle_request_noblock
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
308, in process_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
321, in finish_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
639, in __init__
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
693, in finish
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 242, in close
AttributeError: 'NoneType' object has no attribute 'RawIOBase'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
294, in http_server
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
267, in handle_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
284, in _handle_request_noblock
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
340, in handle_error
ImportError: No module named traceback

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
297, in http_server
AttributeError: 'NoneType' object has no attribute 'timeout'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 509,
in _bootstrap_inner
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 462,
in run
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
300, in http_server
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 178, in close
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 173, in
_real_close
AttributeError: 'NoneType' object has no attribute 'socket'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 527,
in _bootstrap_inner
AttributeError: 'Thread' object has no attribute '_exc_info'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 482,
in _bootstrap
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 557,
in _bootstrap_inner
AttributeError: __exit__
[101191 refs]

1 test failed:
test_xmlrpc
Unhandled exception in thread started by >
Error in sys.excepthook:
TypeError: 'NoneType' object is not callable

Original exception was:
Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
282, in _handle_request_noblock
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
308, in process_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
321, in finish_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
639, in __init__
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
693, in finish
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 242, in close
AttributeError: 'NoneType' object has no attribute 'RawIOBase'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
294, in http_server
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
267, in handle_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
284, in _handle_request_noblock
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
340, in handle_error
ImportError: No module named traceback

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
297, in http_server
AttributeError: 'NoneType' object has no attribute 'timeout'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 509,
in _bootstrap_inner
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 462,
in run
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlr

[issue7055] Automatic test___all__

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r75312, r75314. I'm not sure this should be backported to
2.6 and 3.1 (although it might be useful).

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

[issue7101] tarfile: OSError with TarFile.add(..., recursive=True) about non-existing file

[Denis Martinez]

New submission from Denis Martinez :

I have written a server backup script (file attached) which archives a
list of directories with tarfile and uploads the file to FTP. Today, the
script hanged, with an exception:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 525, in __bootstrap_inner
self.run()
  File "./backup.py", line 48, in run
tar.add(file_or_directory, recursive=True)
  File "/usr/lib/python2.6/tarfile.py", line 1981, in add
self.add(os.path.join(name, f), os.path.join(arcname, f), recursive,
exclude)
  File "/usr/lib/python2.6/tarfile.py", line 1965, in add
tarinfo = self.gettarinfo(name, arcname)
  File "/usr/lib/python2.6/tarfile.py", line 1834, in gettarinfo
statres = os.lstat(name)
OSError: [Errno 2] No such file or directory: '/srv/myfile.htdigest'

What I did here is that I removed the htdigest file while the tarfile
was archiving /srv. I haven't managed to reproduce the bug a second time.
It seems normal that tarfile shouldn't fail is this case; maybe it needs
some exception checking around the stat/lstat calls.

--
components: Library (Lib)
files: backup2.py
messages: 93845
nosy: denis
severity: normal
status: open
title: tarfile: OSError with TarFile.add(..., recursive=True) about 
non-existing file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15098/backup2.py

___
Python tracker 

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

[issue7084] printing a list releases the GIL carelessly

[Scott Dial]

Scott Dial  added the comment:

I've attached a patch that fixes this issue by grabbing a reference to
the item to be printed just before releasing the GIL.

--
keywords: +patch
nosy: +scott.dial
Added file: http://bugs.python.org/file15099/list_print-r75317.patch

___
Python tracker 

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

[issue1578269] Add os.link() and os.symlink() and os.path.islink() support for Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Thanks to some hints by eric.smith, I've run the regression tests with
this patch applied. It turns out there are still some outstanding issues
with draft 9.

One issue was in test_glob.py where broken symlinks would fail to be
matched by glob. This was due to the fact that lexists still needed to
be implemented in ntpath.py. Draft 10 includes this capability.

Another problem the regression tests elicited is more insidious. The
patch breaks test_os.test_1686475, which references issue1686475. The
new symlink-aware stat must traverse symlinks. Unfortunately, the
current method of resolving the symlink target (as recommended by
Microsoft) fails to work if the symlink target is in use (or otherwise a
handle cannot be obtained). Unfortunately, it's not possible to call
GetFinalPathNameByHandle without a handle, the same way as issue1686475
was addressed by using a different API call.

I'm still devising a workaround for this undesirable behavior, but I
wanted to report that progress is still being made and I wanted to
capture the intermediate patch for posterity.

Stay tuned for more info.

--
Added file: http://bugs.python.org/file15100/windows symlink draft 10.patch

___
Python tracker 

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

[issue6894] urllib2 doesn't respect "no_proxy" environment (python2.6.2)

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Fixed in trunk and Committed revision 75333.

--
resolution:  -> fixed

___
Python tracker 

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
nosy:  -loewis

___
Python tracker 

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

[issue6894] urllib2 doesn't respect "no_proxy" environment (python2.6.2)

[Senthil Kumaran]

Senthil Kumaran  added the comment:

merged into py3k revision 75334
merged into release-26maint revision 75335.

--

___
Python tracker 

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

[issue6894] urllib2 doesn't respect "no_proxy" environment (python2.6.2)

[Senthil Kumaran]

Senthil Kumaran  added the comment:

merged in release31-maint in revision 75336

Closing the issue.

--
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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