[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Mart Sõmermaa  added the comment:

Ah, right you are. Attaching an initial alpha-quality patched shutil.py
and a script to test the attack.

Run the script by sourcing it with . test_issue4489.sh, not by executing
(job control won't work in this case).

Added file: http://bugs.python.org/file12482/shutil_patched.py

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Changes by Mart Sõmermaa :


Added file: http://bugs.python.org/file12483/test_issue4489.sh

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Mart Sõmermaa  added the comment:

And here's the diff so you can review what I was up to.

Note that this does not yet fix the problem (although the logic looks
about right), I have to examine the problem more thoroughly.

--
keywords: +patch
Added file: http://bugs.python.org/file12484/issue4489_first_attempt.diff

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Mart Sõmermaa  added the comment:

Aha, got it -- while removing /a/b/c/d, there's no easy way to detect
that b or c has become a symlink.

I.e.

given directory tree

a
`-- b
|-- c
`-- d

1. os.rmdir('/a/b/c') succeeds
2. execution is suspended
3. '/a/b' is made a symlink to a path that contains 'd'
4. '/a/b/d' is neither a symlink, nor has it's inode been recorded, so
os.rmdir('/a/b/d') succeeds

I'm afraid the solution for the Perl bug is susceptible to the same problem.

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Mart Sõmermaa  added the comment:

A blunt, ineffective solution would be to walk the tree before removing
it and recording path : inode pairs in a dict on first pass and then
checking that the inodes have not changed during removal on second pass.

If no clever bulletproof fix emerges, perhaps this should be added as
shutil.rmtree_safe (duh, API bloat...)?

___
Python tracker 

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

[issue3671] What's New in 2.6 - corrections

[Georg Brandl]

Changes by Georg Brandl :


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

[issue3644] ``make htmlview`` for docs fails on OS X

[Georg Brandl]

Changes by Georg Brandl :


--
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> A blunt, ineffective solution would be to walk the tree before removing
> it and recording path : inode pairs in a dict on first pass and then
> checking that the inodes have not changed during removal on second pass.

There's no way to do the "check inode then remove" sequence atomically.

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Changes by Mart Sõmermaa :


Removed file: http://bugs.python.org/file12483/test_issue4489.sh

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Mart Sõmermaa  added the comment:

Fixed a minor bug in test script and added Perl test as well.

Perl with File-Path-2.07 passes the test.

Added file: http://bugs.python.org/file12485/test_issue4489.sh

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Mart Sõmermaa  added the comment:

Antoine, what if we add another function, rmtree_safe() that uses
chdir() and document that it is protected from the race condition but
may have the side effect of changing the current dir in threaded
environment?

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Antoine, what if we add another function, rmtree_safe() that uses
> chdir() and document that it is protected from the race condition but
> may have the side effect of changing the current dir in threaded
> environment?

I don't have any strong opinion on it, maybe it should be brought on the
mailing-list (or just wait for some other devs to show up here).

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Mart Sõmermaa]

Mart Sõmermaa  added the comment:

Replying to previous comment:

> There's no way to do the "check inode then remove" sequence atomically.

Right, although the attack window would be tiny, this is not a real
solution.

___
Python tracker 

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

[issue4750] tarfile keeps excessive dir structure in compressed files

[anatoly techtonik]

anatoly techtonik  added the comment:

For MSYS gzip added a bugreport here:
https://sourceforge.net/tracker2/index.php?func=detail&aid=2474481&group_id=2435&atid=102435

___
Python tracker 

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

[issue4732] Object allocation stress leads to segfault on RHEL

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think you should report the bug to Redhat and see what they have to
say about it. It may be a bug in the libc of that particular version. In
any case I think it is highly inlikely to be a bug in Python itself.

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Antoine Pitrou]

Antoine Pitrou  added the comment:

FWIW, I've opened a separate bug entry for the creation of the openat(),
etc. wrappers: #4761.
Those functions seem to exist on recent Linux distros (even Debian stable).

___
Python tracker 

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

[issue4746] Misguiding wording 3.0 c-api reference

[ebfe]

ebfe  added the comment:

Whenever the documentation says "you must not" it really says "don't do
that or your application *will* crash, burn and die"... Of course I can
allocate storage for the string, copy it's content and then free or -
nothing will happen. How would it cause a crash - it's my own pointer.

That's exactly the line between "not required to", "should not" and
"must not": The current wording suggests that I may not even touch e.g.
malloc which is confusing and in fact to be ignored in it's current state.

___
Python tracker 

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

[issue4746] Misguiding wording 3.0 c-api reference

[Antoine Pitrou]

Antoine Pitrou  added the comment:

For me, when I read "You must not provide storage for the string
itself", it obviously means I mustn't do so *before calling the
PyArg_ParseTuple function*. It is also obvious that I am allowed to copy
the returned contents wherever I want, and it should be obvious to any C
programmer. So I don't see how the wording is misleading.

--
nosy: +pitrou

___
Python tracker 

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

[issue4746] Misguiding wording 3.0 c-api reference

[Martin v. Löwis]

Martin v. Löwis  added the comment:

> Whenever the documentation says "you must not" it really says "don't do
> that or your application *will* crash, burn and die"... Of course I can
> allocate storage for the string, copy it's content and then free or -
> nothing will happen. How would it cause a crash - it's my own pointer.

Suppose you do

  char *s = malloc(MAXPATH);
  if (!PyArg_ParseTuple("s", &s))return NULL;
  do_something_with(s);
  free(s);

then your application *will* crash, burn, and die - because s gets
changed in the call; the original malloc result is garbage, and the
free call will likely crash the malloc implementation (as the block
it points to wasn't malloc-allocated, and isn't the beginning of a
block).

___
Python tracker 

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

[issue4746] Misguiding wording 3.0 c-api reference

[Georg Brandl]

Georg Brandl  added the comment:

I don't see a reason to keep this open any longer.

--
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue4766] email documentation needs to be precise about strings/bytes

[David M. Beazley]

New submission from David M. Beazley :

Documentation for the email package needs to be more clear about the 
usage of strings and bytes.  In particular:

1.  All operations that parse email messages such as message_from_file()
or message_from_string() operate on *text*, not binary data.  So,
the file must be opened in text mode.  Strings must be text strings,
not binary strings.

2.  All operations that set/get the payload of a message operate on
byte strings.   For example, using m.get_payload() on a Message
object returns binary data as a byte string.

Opinion:  There might be other bug reports about this, but I'm not 
advocating that the email module should support reading messages from 
binary mode files or byte strings.  Email and MIME were originally 
developed with the assumption that messages would always be handled as 
text. Minimally, this assumed that messages would stay intact even if 
processed as 7-bit ASCII.   By extension, everything should still work 
if processed as Unicode.  So, I think the use of text-mode files is 
entirely consistent with this if you wanted to keep the module "as is." 

There may be some confusion on this matter because if you're reading or 
writing email messages (or sending them across a socket), you may 
encounter messages stored in the form of bytes strings instead of text.   
People will then wonder why a byte string can't be parsed by this module 
(especially given that email messages only use character values in the 
range of 0-127).

--
assignee: georg.brandl
components: Documentation
messages: 78456
nosy: beazley, georg.brandl
severity: normal
status: open
title: email documentation needs to be precise about strings/bytes
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

[issue4766] email documentation needs to be precise about strings/bytes

[Georg Brandl]

Changes by Georg Brandl :


--
assignee: georg.brandl -> barry
nosy: +barry

___
Python tracker 

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

[issue4643] cgitb.html fails if getattr call raises exception

[Allan Crooks]

Allan Crooks  added the comment:

In the interests of getting this fixed (and not letting it die), should
I submit a proper patch? I suppose I would have to do one for each
version of Python that is affected (which is all of them, really).

___
Python tracker 

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

[issue4767] email.mime incorrectly documented (or implemented)

[David M. Beazley]

New submission from David M. Beazley :

The documentation describes classes such as

email.mime.MIMEText()
email.mime.MIMEMultipart()
email.mime.MIMEApplication()
etc...

However, it's confusing because none of these classes are actually found 
in email.mime.

Suggest either using the full proper name:

   email.mime.text.MIMEText()

Or just using the short name along with a note saying where it's found:

   MIMEText()
   Defined in email.mime.text.  Further description, blah, blah..

Note:  These classes *are* defined in email.mime in Python 2.6.

--
assignee: georg.brandl
components: Documentation
messages: 78458
nosy: beazley, georg.brandl
severity: normal
status: open
title: email.mime incorrectly documented (or implemented)
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

[issue3248] ScrolledText can't be placed in a PanedWindow

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Notice that the example function doesn't actually work; it gives

_tkinter.TclError: wrong # args: should be ".148002724.148002500 insert
index chars ?tagList chars tagList ...?"

___
Python tracker 

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

[issue3248] ScrolledText can't be placed in a PanedWindow

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Thanks again for the patch. Merged into recent branches as r68006,
r68007, r68008, and r68009

___
Python tracker 

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

[issue3248] ScrolledText can't be placed in a PanedWindow

[Martin v. Löwis]

Changes by Martin v. Löwis :


--
resolution:  -> accepted
status: open -> closed

___
Python tracker 

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

[issue3248] ScrolledText can't be placed in a PanedWindow

[Guilherme Polo]

Guilherme Polo  added the comment:

On Mon, Dec 29, 2008 at 2:02 PM, Martin v. Löwis  wrote:
>
> Martin v. Löwis  added the comment:
>
> Notice that the example function doesn't actually work; it gives
>
> _tkinter.TclError: wrong # args: should be ".148002724.148002500 insert
> index chars ?tagList chars tagList ...?"

The example function included didn't work for you ? I guess I
misunderstood your message otherwise you wouldn't have commited it.

___
Python tracker 

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

[issue3767] tkColorChooser may fail if no color is selected

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Committed into various branches as r68010, r68011, r68012, and r68013

--
status: open -> closed

___
Python tracker 

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

[issue3432] Mac, 2.6 framework install error

[Alan Brooks]

Alan Brooks  added the comment:

I also get this exact same problem. Mac OS 10.5.6 on an Intel MacBook 
trying to install the release version of 2.6.1. I found it was failing to 
build _Res, but worked around by *not* using --enable-universalsdk.

--
nosy: +lanny

___
Python tracker 

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

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

[David M. Beazley]

New submission from David M. Beazley :

The email.generator.Generator class does not work correctly message 
objects created with binary data (MIMEImage, MIMEAudio, MIMEApplication, 
etc.).  For example:

>>> from email.mime.image import MIMEImage
>>> data = open("IMG.jpg","rb").read()
>>> m = MIMEImage(data,'jpeg')
>>> s = m.as_string()
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/lib/python3.0/email/message.py", line 136, in as_string
g.flatten(self, unixfrom=unixfrom)
  File "/tmp/lib/python3.0/email/generator.py", line 76, in flatten
self._write(msg)
  File "/tmp/lib/python3.0/email/generator.py", line 101, in _write
self._dispatch(msg)
  File "/tmp/lib/python3.0/email/generator.py", line 127, in _dispatch
meth(msg)
  File "/tmp/lib/python3.0/email/generator.py", line 155, in 
_handle_text
raise TypeError('string payload expected: %s' % type(payload))
TypeError: string payload expected: 
>>> 

The source of the problem is rather complicated, but here is the gist of 
it.

1.  Classes such as MIMEAudio and MIMEImage accept raw binary data as 
input.  This data is going to be in the form of bytes.

2.  These classes immediately encode the data using a base64 encoder. 
This encoder uses the library function base64.b64encode().

3. base64.b64encode() takes a byte string as input and returns a byte 
string as output.  So, even after encoding, the payload of the message 
is of type 'bytes'

4. When messages are generated, the method Generator._dispatch() is 
used.   It looks at the MIME main type and subtype and tries to dispatch 
message processing to a handler method of the form 
'_handle_type_subtype'.If it can't find such a handler, it defaults 
to a method _writeBody().  For image and audio types, this is what 
happens. 

5. _writeBody() is an alias for _handle_text().

6. _handle_text() crashes because it's not expecting a payload of type 
'bytes'.

Suggested fix:

I think the library function base64.b64encode() should return a string, 
not bytes.  The whole point of base64 encoding is to take binary data 
and encode it into characters safe for inclusion in text strings. 

Other fixes:

Modify the Generator class in email.generator to properly detect bytes 
and use a different _handle function for it.  For instance, maybe add a 
_handle_binary() method.

--
components: Library (Lib)
messages: 78464
nosy: beazley
severity: normal
status: open
title: email.generator.Generator object bytes/str crash - b64encode() bug?
type: crash
versions: Python 3.0

___
Python tracker 

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

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Nick, sorry for waving at you again, but do you have time for a review?
Otherwise, is it ok if I commit the patch as is?
(it solves the problems and there's no API or feature change anyway)

___
Python tracker 

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

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> barry
nosy: +barry

___
Python tracker 

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

[issue4769] b64decode should accept strings or bytes

[David M. Beazley]

New submission from David M. Beazley :

The whole point of base64 encoding is to safely encode binary data into 
text characters.  Thus, the base64.b64decode() function should equally 
accept text strings or binary strings as input. For example, there is a 
reasonable expectation that something like this should work:

>>> x = 'SGVsbG8='
>>> base64.b64decode(x)
b'Hello'
>>>

In Python 3, you get this exception however:

>>> base64.b64decode(x)
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/lib/python3.0/base64.py", line 80, in b64decode
raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not str
>>> 

I realize that there are encoding issues with Unicode strings, but 
base64 encodes everything into the first 127 ASCII characters.  If the 
input to b64decode is a str, just do a encode('ascii') operation on it 
and proceed.  If that fails, it wasn't valid Base64 to begin with.

I can't think of any real negative impact to making this change as long 
as the result is still always bytes.   The main benefit is just 
simplifying the decoding process for end-users.

See issue 4768.

--
components: Library (Lib)
messages: 78466
nosy: beazley
severity: normal
status: open
title: b64decode should accept strings or bytes
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

[issue1034053] unittest.py patch: add skipped test functionality

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I think this is a good improvement, and I hope it can make it into 2.7/3.1.

Several comments on patch:

- I don't like the name "SkipException" SkipTest is better IMO.

- TestResult.addSkipped should be changed to TestResult.addSkip.

- I'm not sure why TestResult.addSkipped gets sys.exc_info() pass in. I
think you should just catch the exception and pass the reason ("str(e)")
to addSkipped.

- The patch needs docs before it can be applied.

- As Antoine said, it would be nice to have decorators for skipping.
When I implemented this, I added the skip() (unconditional skip)
skip_if(condition, reason) and skip_unless(condition, reason)
decorators. It should also be easy to extend the mechanism, so that
custom decorators can be written.

- It would nice to be able to skip whole classes, too. This could easily
be done with class decorators.

(Georg, I hope you don't mind if I "steal" this from you.)

--
assignee: georg.brandl -> benjamin.peterson
nosy: +benjamin.peterson

___
Python tracker 

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

[issue4769] b64decode should accept strings or bytes

[David M. Beazley]

David M. Beazley  added the comment:

Note: This problem applies to all of the other decoders/encoders in the 
base64 too (b16, b32, etc.)

___
Python tracker 

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

[issue4764] open('existing_dir') -> IOError instance's attr filename is None

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r68014 and r68016.

--
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[David M. Beazley]

New submission from David M. Beazley :

See Issue 4869 for a related bug.

Most of the functions in binascii are meant to go from binary data to 
textual representations (hex digits, base64, binhex, etc.).  There are 
numerous problems:

1.  Misleading error messages.  For example:

>>> binascii.b2a_base64("Some text")
Traceback (most recent call last):
  File "", line 1, in 
TypeError: b2a_base64() argument 1 must be string or buffer, not str
>>> binascii.crc32("Some text")
Traceback (most recent call last):
  File "", line 1, in 
TypeError: crc32() argument 1 must be string or buffer, not str
>>>

Huh?  Didn't I just pass a string?   Error message should say "argument 
1 must be bytes or buffer, not str".

This problem shows up with most of the other encoding functions too 
(i.e., b2a_uu).

2. Expected behavior with encoding/decoding.

The functions in this module are going from binary to text. To be 
consistent, I think the result of encoding operations such as b2a_uu(),
b2a_base64(), should be strings, not bytes.

Similarly, decoding operations are going from text back to bytes.  I 
think the input arguments should be allowed to be str (in addition to 
bytes if you want).

--
components: Library (Lib)
messages: 78470
nosy: beazley
severity: normal
status: open
title: binascii module, crazy error messages, unexpected behavior
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

[issue4400] pypirc default is not at the right format

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The patch was applied in trunk, release26-maint and py3k.
Can this issue be closed, or do you plan to merge it into release30-maint?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue1040026] os.times() is bogus

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Malte, thanks again for the patch; committed into the various branches
as r68018, r68019, r68020, r68021.

As annunciated, I reject the test; I don't think there is a reasonable
way to test for this bug.

--
status: open -> closed

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Item 1 was most probably fixed recently with r67929.
Concerning item 2, I think it was decided that binascii is a bytes-only
module.

I suggest to close this issue as "out of date".

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue4323] Wrong encoding in files saved from IDLE (3.0rc2 on Windows)

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Thanks for the review. Committed (with the proposed change) as r68022
and r68023.

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[David M. Beazley]

David M. Beazley  added the comment:

Given the low-level nature of this module, I can understand the 
motivation to make it all bytes.

However, I'm going to respectfully disagree with that and claim that 
making binascii all bytes really goes against the whole spirit of what 
Python 3.0 has tried to do for Unicode.  For example, throughout Python, 
you now have a clean separation between binary data (bytes) and text 
data (str).   Well, it's cleanly separated everywhere except in the 
binascii module (and base64 module) which, ironically, is all about 
converting between binary data and text.

As it stands now, it's a huge wart IMHO.

___
Python tracker 

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

[issue4049] IDLE does not open too

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Since there was no feedback from the OP, I'm closing this as "works for me".

--
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue4623] IDLE shutdown if I run an edited file contains chinese

[Martin v. Löwis]

Martin v. Löwis  added the comment:

This is a duplicate of issue 4008.

--
nosy: +loewis
resolution:  -> duplicate
status: open -> closed
superseder:  -> IDLE: checksyntax() doesn't support Unicode?

___
Python tracker 

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

[issue4410] IDLE string problem in Run/Run Module

[Martin v. Löwis]

Martin v. Löwis  added the comment:

This is a duplicate of issue 4008

--
nosy: +loewis
resolution:  -> duplicate
status: open -> closed
superseder:  -> IDLE: checksyntax() doesn't support Unicode?

___
Python tracker 

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

[issue4008] IDLE: checksyntax() doesn't support Unicode?

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Here is a new patch that fixes this issue, and the duplicate issues
(#4410, and #4623).

It doesn't try to eliminate code duplication, but fixes coding_spec by
decoding always to Latin-1 first until the coding is known. It fixes
check_syntax by opening the source file in binary. It should have fixed
tabnanny the same way, except that tabnanny cannot properly process byte
tokens.

--
keywords: +needs review
priority:  -> release blocker
Added file: http://bugs.python.org/file12486/idle_encoding_4.patch

___
Python tracker 

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

[issue4771] Bad examples in hashlib documentation

[David M. Beazley]

New submission from David M. Beazley :

The hashlib documentation has incorrect examples showing the use of the 
hexdigest() method:

>>> hashlib.sha224(b"Nobody inspects the spammish 
repetition").hexdigest()
b'a4337bc45a8fc544c03f52dc550cd6e1e87021bc896588bd79e901e2'
>>>

and this one

>>> h = hashlib.new('ripemd160')
>>> h.update(b"Nobody inspects the spammish repetition")
>>> h.hexdigest()
b'cc4a5ce1b3df48aec5d22d1f16b894a0b894eccc'
>>>

However, the result of h.hexdigest() is of type 'str', not bytes. Actual 
output:

>>> h.hexdigest()
'cc4a5ce1b3df48aec5d22d1f16b894a0b894eccc'
>>> 

Sure would be nice if that string of hex digits was easy to decode back 
into a binary string.  

>>> import binascii
>>> b = binascii.a2b_hex(h.hexdigest())
>>>

Hmmm. So *SOME* of the functions in binascii do accept Unicode strings. 
See Issue 4470 :-).

--
assignee: georg.brandl
components: Documentation
messages: 78480
nosy: beazley, georg.brandl
severity: normal
status: open
title: Bad examples in hashlib documentation
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

[issue4771] Bad examples in hashlib documentation

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Shouldn't hash algorithms give bytes results anyway?

--
components: +Library (Lib) -Documentation
nosy: +benjamin.peterson
priority:  -> release blocker

___
Python tracker 

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

[issue4771] Bad examples in hashlib documentation

[David M. Beazley]

David M. Beazley  added the comment:

The digest() method of hashes does produce bytes (correct).   The 
hexdigest() method produces a string, but it is also shown as producing 
bytes in the examples.

___
Python tracker 

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

[issue4772] undesired switch fall-through in socketmodule.c

[dontbugme]

New submission from dontbugme :

makesockaddr() in socketmodule.c will fall through from AF_BLUETOOTH to
AF_PACKET if none of Bluetooth protocols match. That's not a very
appropriate thing to do.

--
messages: 78483
nosy: dontbugme
severity: normal
status: open
title: undesired switch fall-through in socketmodule.c

___
Python tracker 

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

[issue4771] Bad examples in hashlib documentation

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r68027.

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

[issue4400] pypirc default is not at the right format

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Yes, I was waiting to merge it to release30-maint then close it. 
I'll do it then close it.

___
Python tracker 

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

[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0

[David M. Beazley]

New submission from David M. Beazley :

A file-like object u returned by the urlopen() function in both Python 
2.6/3.0 has a method info() that returns a 'HTTPMessage' object.  For 
example:

::: Python 2.6
>>> from urllib2 import urlopen
>>> u = urlopen("http://www.python.org";)
>>> u.info()

>>> 

::: Python 3.0
>>> from urllib.request import urlopen
>>> u = urlopen("http://www.python.org";)
>>> u.info()

>>>

So far, so good.  HTTPMessage is defined in two different modules, but 
that's fine (it's just library reorganization).

Two major problems:

1. There is no documentation whatsoever on HTTPMessage.  No description 
in the docs for httplib (python 2.6) or http.client (python 3.0).

2. The HTTPMessage object in Python 2.6 derives from mimetools.Message 
and has a totally different programming interface than HTTPMessage in 
Python 3.0 which derives from email.message.Message.  Check it out:

:::Python 2.6
>>> dir(u.info())
['__contains__', '__delitem__', '__doc__', '__getitem__', '__init__', 
'__iter__', '__len__', '__module__', '__setitem__', '__str__', 
'addcontinue', 'addheader', 'dict', 'encodingheader', 'fp', 'get', 
'getaddr', 'getaddrlist', 'getallmatchingheaders', 'getdate', 
'getdate_tz', 'getencoding', 'getfirstmatchingheader', 'getheader', 
'getheaders', 'getmaintype', 'getparam', 'getparamnames', 'getplist', 
'getrawheader', 'getsubtype', 'gettype', 'has_key', 'headers', 
'iscomment', 'isheader', 'islast', 'items', 'keys', 'maintype', 
'parseplist', 'parsetype', 'plist', 'plisttext', 'readheaders', 
'rewindbody', 'seekable', 'setdefault', 'startofbody', 'startofheaders', 
'status', 'subtype', 'type', 'typeheader', 'unixfrom', 'values']

:::Python 3.0
>>> dir(u.info())
['__class__', '__contains__', '__delattr__', '__delitem__', '__dict__', 
'__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', 
'__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', 
'__len__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__', '_charset', 
'_default_type', '_get_params_preserve', '_headers', '_payload', 
'_unixfrom', 'add_header', 'as_string', 'attach', 'defects', 
'del_param', 'epilogue', 'get', 'get_all', 'get_boundary', 
'get_charset', 'get_charsets', 'get_content_charset', 
'get_content_maintype', 'get_content_subtype', 'get_content_type', 
'get_default_type', 'get_filename', 'get_param', 'get_params', 
'get_payload', 'get_unixfrom', 'getallmatchingheaders', 'is_multipart', 
'items', 'keys', 'preamble', 'replace_header', 'set_boundary', 
'set_charset', 'set_default_type', 'set_param', 'set_payload', 
'set_type', 'set_unixfrom', 'values', 'walk']

I know that getting rid of mimetools was desired, but I have no idea if 
changing the API on HTTPMessage was intended or not.  In any case, it's 
one of the only cases in the entire library where the programming 
interface to an object radically changes from 2.6 -> 3.0.  

I ran into this problem with code that was trying to properly determine 
the charset encoding of the byte string returned by urlopen(). 

I haven't checked whether 2to3 deals with this or not, but it might be 
something for someone to look at in their copious amounts of spare time.

--
components: Library (Lib)
messages: 78486
nosy: beazley
severity: normal
status: open
title: HTTPMessage not documented and has inconsistent API across 2.6/3.0
type: behavior
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

[issue4400] pypirc default is not at the right format

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I am not sure what is the best way to merge it from 3k branch to
release30-maint since the original change was done with an automatic
merge from trunk to 3k branch with several other changes, then a slight
fix so the 2.x code works under 3.x.

Should I do a manual merge in release30-maint or there's a special way
to handle it ?

___
Python tracker 

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

[issue4673] Distutils should provide an uninstall command

[Tarek Ziadé]

Tarek Ziadé  added the comment:

This would require a detailed description on how such a feature would work.

--
nosy: +tarek

___
Python tracker 

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

[issue4400] pypirc default is not at the right format

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Assigning to Benjamin, since he merged the change to 3k.

For the record, the revisions are these: r67926, r67944, r67948

--
assignee: tarek -> benjamin.peterson
nosy: +benjamin.peterson, loewis
priority:  -> release blocker

___
Python tracker 

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

[issue4400] pypirc default is not at the right format

[Benjamin Peterson]

Benjamin Peterson  added the comment:

On Mon, Dec 29, 2008 at 3:51 PM, Martin v. Löwis  wrote:
>
> Martin v. Löwis  added the comment:
>
> Assigning to Benjamin, since he merged the change to 3k.
>
> For the record, the revisions are these: r67926, r67944, r67948

And now r68031.

___
Python tracker 

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

[issue4400] pypirc default is not at the right format

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
status: open -> closed

___
Python tracker 

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

[issue4646] distutils chokes on empty options arg in the setup function

[Tarek Ziadé]

Changes by Tarek Ziadé :


--
assignee:  -> tarek
nosy: +tarek
priority:  -> low
resolution:  -> accepted

___
Python tracker 

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

[issue4755] Common path prefix

[Jeff Hall]

Changes by Jeff Hall :


--
nosy: +laxrulz777

___
Python tracker 

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

[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0

[David M. Beazley]

David M. Beazley  added the comment:

Verified that 2to3 does not fix this.

___
Python tracker 

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

[issue4646] distutils chokes on empty options arg in the setup function

[Tarek Ziadé]

Tarek Ziadé  added the comment:

applied with a test in r68033, thanks for the patch !

--
status: open -> closed

___
Python tracker 

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

[issue4750] tarfile keeps excessive dir structure in compressed files

[anatoly techtonik]

anatoly techtonik  added the comment:

I attach patch for Python 2.6 gzip
I clarified the meaning of self.name to be the basename corresponding to
FNAME field in GZIP file header.

There is a trace of deprecated gzip.filename API - I haven't found any
references to it in documentation, so I removed it. In Python 2.5 it
seemed to mean just filename in read mode and filename + .gz in write
mode even if opened filename did not end with .gz

If FNAME field from gzip header is ignored in read mode, so we want to
make self.filename or self.name available via API - we need to agree
what it should be - basename of archived file or path filename of
archive itself.

Added file: http://bugs.python.org/file12487/4750.gzip.basename.fix.diff

___
Python tracker 

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

[issue4774] threding, bsddb and double free or corruption (fasttop)

[Alain Spineux]

New submission from Alain Spineux :

This is a test script, to help me to understand why I have unexpected
result in application.
But I got a more unexpected result, and probably wrong error message
about the read-only cursor.
The full script is at the end.

I got this only one ! I restart the script after the crash, but
this has freezed my xen virtual machine after some minutes. I had to
"destroy" it and restart it. 
After restart was not working anymore, blocked, not responding except to
CTRL-C
I had to drop the old DB, and then i worked again 

I run python 2.5.2 inside a kolab 2.2.0 (aka openpkg) environement 
on a xen centos 5.x running kernel 2.6.18-8.el5xen and glibc-2.5-12

The host is a P4 running centos 5.X and kernel 2.6.18-53.1.4.el5xen


Here are the errors, I waited for long time after the  firts backtrace,
to press CTRL-C and got immediately the second backtrace.

Regards

db cleanup, 326 records deleted, 9990 remains
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/kolab/lib/python/threading.py", line 486, in
__bootstrap_inner
self.run()
  File "/kolab/lib/python/threading.py", line 446, in run
self.__target(*self.__args, **self.__kwargs)
  File "./test/test_bdb.py", line 85, in 
update_thread=threading.Thread(target=lambda : cleanup(db))
  File "./test/test_bdb.py", line 72, in cleanup
cursor.delete()
DBPermissionsError: (1, 'Operation not permitted -- Write attempted on
read-
only
cursor')

Traceback (most recent call last):
  File "./test/test_bdb.py", line 130, in 
server()
  File "./test/test_bdb.py", line 92, in server
db[str(last)]=str(last)
KeyboardInterrupt
*** glibc detected *** /kolab/bin/python: double free or corruption
(fasttop):
0
x09d521a8 ***
=== Backtrace: =
/lib/i686/nosegneg/libc.so.6[0xccfd]
/lib/i686/nosegneg/libc.so.6(cfree+0x90)[0x444503b0]
/kolab/bin/python(__db_c_destroy+0x60)[0x81fa6f0]
/kolab/bin/python(__db_refresh+0x165)[0x81f3515]
/kolab/bin/python(__db_close+0x64)[0x81f3cb4]
/kolab/bin/python(__db_close_pp+0xa1)[0x8204b61]
/kolab/bin/python[0x812123f]
/kolab/bin/python[0x8159534]
/kolab/bin/python[0x815fb0a]
/kolab/bin/python[0x811abbc]
/kolab/bin/python[0x811abc9]
/kolab/bin/python[0x80b0229]
/kolab/bin/python(PyDict_SetItem+0x6e)[0x80b1c0e]
/kolab/bin/python(PyDict_SetItemString+0x42)[0x80b1ce2]
/kolab/bin/python(PyImport_Cleanup+0xd4)[0x8108294]
/kolab/bin/python(Py_Finalize+0xbf)[0x8113f1f]
/kolab/bin/python(Py_Main+0x468)[0x80845c8]
/kolab/bin/python(main+0x22)[0x8084052]
/lib/i686/nosegneg/libc.so.6(__libc_start_main+0xdc)[0x443fbdec]
/kolab/bin/python[0x8083fa1]
=== Memory map: 
0011-001d7000 rwxp 0011 00:00 0
001d7000-001da000 r-xp  ca:03 973941 /kolab/lib/python/lib-
dynload/
t
ime.so
001da000-001dc000 rwxp 2000 ca:03 973941 /kolab/lib/python/lib-
dynload/
t
ime.so
001dc000-001e r-xp  ca:03 973938 /kolab/lib/python/lib-
dynload/
s
trop.so
001e-001e2000 rwxp 3000 ca:03 973938 /kolab/lib/python/lib-
dynload/
s
trop.so
001e2000-001e3000 r-xp  ca:03 973911 /kolab/lib/python/lib-
dynload/
_
weakref.so
001e3000-001e4000 rwxp  ca:03 973911 /kolab/lib/python/lib-
dynload/
_
weakref.so
001e4000-001ea000 rwxs  ca:03 1747650/tmp/db/__db.001
001ea000-001fc000 rwxs  ca:03 1747651/tmp/db/__db.002
001fc000-0023e000 rwxs  ca:03 1747652/tmp/db/__db.003
00388000-003e rwxs  ca:03 1747653/tmp/db/__db.004
0045-00452000 r-xp  ca:03 1132355/lib/libutil-2.5.so
00452000-00453000 r-xp 1000 ca:03 1132355/lib/libutil-2.5.so
00453000-00454000 rwxp 2000 ca:03 1132355/lib/libutil-2.5.so
00459000-0047e000 r-xp  ca:03 1132349/lib/i686/nosegneg/
libm-2.5.so
0047e000-0047f000 r-xp 00024000 ca:03 1132349/lib/i686/nosegneg/
libm-2.5.so
0047f000-0048 rwxp 00025000 ca:03 1132349/lib/i686/nosegneg/
libm-2.5.so
0063e000-0063f000 r-xp 0063e000 00:00 0  [vdso]
0097a000-0098d000 r-xp  ca:03 1134447/lib/i686/nosegneg/
libpthread-2   
  .
5.so
0098d000-0098e000 r-xp 00012000 ca:03 1134447/lib/i686/nosegneg/
libpthread-2   
  .
5.so
0098e000-0098f000 rwxp 00013000 ca:03 1134447/lib/i686/nosegneg/
libpthread-2   
  .
5.so
0098f000-00991000 rwxp 0098f000 00:00 0
009a8000-009e9000 rwxp 009a8000 00:00 0
00b8-00d8 r-xp  ca:03 845325 /usr/lib/locale/
locale-archive
00ec9000-00ecc000 r-xp  ca:03 973916 /kolab/lib/python/lib-
dynload/
c
StringIO.so
00ecc000-00ecd000 rwxp 3000 ca:03 973916 /kolab/lib/python/lib-

[issue4774] threding, bsddb and double free or corruption (fasttop)

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> jcea
nosy: +jcea

___
Python tracker 

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

[issue3023] Problem with invalidly-encoded command-line arguments (Unix)

[dedded]

Changes by dedded :


--
nosy: +dedded

___
Python tracker 

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

[issue4774] threding, bsddb and double free or corruption (fasttop)

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

Alain, you are seeing a resource exhaustion problem. Somewhere memory is
leaking. That is, the programs are leaking memory.

bsddb was vastly improved in python 2.6. In particular, memory leaks and
resource tree deallocations. Can you consider use that version?.

You can install and updated pybsddb version in python 2.5. See
http://www.jcea.es/programacion/pybsddb.htm. Just remember that the
module is called "bsddb3" instead of "bsddb". You can easily install it
using setuptools ("easy_install" script).

Please, confirm that the problem vanished with the new module.

What Berkeley DB are you using with bsddb bindings?.

___
Python tracker 

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

[issue4701] range objects becomes hashable after attribute access

[Nick Coghlan]

Nick Coghlan  added the comment:

Fixed using a lazy call to PyType_Ready in PyObject_Hash:

2.7: r68051
2.6: r68052

Forward-port to Py3k still to come.

___
Python tracker 

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

[issue4775] Incorrect documentation - UTC time

[David Morley]

New submission from David Morley :

There is a systemic error in the Python documentation on time (such as 
). The term UTC is used 
incorrectly in the documentation where the term UT1 should be used.

The difference is that UTC includes leap seconds, whereas UT1 does not (see 
). The 
conversion routines ignore leap seconds, e.g., 
(time.mktime((2000,1,1,12,0,0,0,0,0))-
time.mktime((1990,1,1,12,0,0,0,0,0))) returns an exact multiple of 
24*60*60 and does not include all the leap seconds added between those 
dates. Using UT1 is more sensible that using UTC, since with UTC it is 
impossible to know when future leap seconds will be added, and hence 
impossible to convert future times to a number of seconds past the 
epoch.

--
assignee: georg.brandl
components: Documentation
messages: 78497
nosy: georg.brandl, luckmor
severity: normal
status: open
title: Incorrect documentation - UTC time
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

[issue3883] Bottom buttons of IDLE Preferences Pane on Mac not wide enough for their text.

[Kevin Walzer]

Kevin Walzer  added the comment:

The attached patch to configDialog.py fixes this problem--all that was 
needed was to remove the internal padding in the buttons.

--
keywords: +patch
nosy: +wordtech
type:  -> behavior
Added file: http://bugs.python.org/file12488/configDialog.patch

___
Python tracker 

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

[issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine

[Guilherme Polo]

Changes by Guilherme Polo :


___
Python tracker 

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

[issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine

[Guilherme Polo]

Guilherme Polo  added the comment:

Jimmy Retzlaff (msg73003):

I'm seeing the same symptoms that are described in issue 1543 with the
2.6b3 MSIs. Namely, when you run one of the MSIs (either 32-bit or
64-bit) then the other will refuse to install. This is on XP Pro x64 SP2.

python-3.0b3.msi and python-3.0b3.amd64.msi exhibit the same problem.

Having 32-bit and 64-bit version coexist makes it much easier to build
extensions for and test on both versions at the same time.


-- Sorry, was going through some issue and unlinked the initial message
by mistake.

--
nosy: +gpolo

___
Python tracker 

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

[issue4760] cmp gone---What's new in 3.1

[Guilherme Polo]

Guilherme Polo  added the comment:

Uhm ? The builtin cmp wasn't removed.

--
nosy: +gpolo

___
Python tracker 

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

[issue4096] Lib/lib2to3/*.pickle are shipped / modified in the build

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Shall we close this as "works for me"? The files aren't included in
Subversion and are built when 2to3 is used, so I don't see the problem.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue4776] distutils documentation

[steve21]

New submission from steve21 :

'data_files' and 'package_dir' are arguments for distutils.core.setup
that some packages use in their setup.py.
However, the manual entry for distutils.core. setup, at
http://docs.python.org/dev/3.0/distutils/apiref.html#module-distutils.core
does not document these arguments.

--
assignee: georg.brandl
components: Documentation
messages: 78502
nosy: georg.brandl, steve21
severity: normal
status: open
title: distutils documentation
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

[issue4643] cgitb.html fails if getattr call raises exception

[Gabriel Genellina]

Gabriel Genellina  added the comment:

I believe a patch against the trunk would be enough, but should include 
a test case.

___
Python tracker 

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

[issue1664] nntplib is not IPv6-capable

[Chris Morrow]

Chris Morrow  added the comment:

This patch doesn't appear to work for python2.5.1 ->

Python 2.5.1 (r251:54863, Jun 15 2008, 18:24:51) 
[GCC 4.3.0 20080428 (Red Hat 4.3.0-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from nntplib import NNTP
>>> conn = NNTP('newszilla6.xs4all.nl')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/nntplib.py", line 114, in __init__
self.sock = socket.create_connection((host, port))
AttributeError: 'module' object has no attribute 'create_connection'


(at least for me it doesn't work...
Linux hostnamehere 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 
2008 i686 i686 i386 GNU/Linux)

I'd be happy to try something else, or debug in other ways it that'd 
help... This really ought to get fixed if possible.

--
nosy: +morrowc

___
Python tracker 

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

[issue1664] nntplib is not IPv6-capable

[Derek Morr]

Derek Morr  added the comment:

Yes. The patch is against 2.6. It uses the socket.create_connection() 
helper function, which was added in 2.6. See http://svn.python.org/view?
rev=54546&view=rev for the commit message.

If you really want to apply it to 2.5, it's trivial to adapt the patch. 
Just replace the call to create_connection() with something like this:

msg = "getaddrinfo returns an empty list"
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
af, socktype, proto, canonname, sa = res
sock = None
try:
sock = socket(af, socktype, proto)
if timeout is not _GLOBAL_DEFAULT_TIMEOUT:
sock.settimeout(timeout)
sock.connect(sa)
self.sock = sock

except error, msg:
if sock is not None:
sock.close()

raise error, msg

___
Python tracker 

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

[issue1664] nntplib is not IPv6-capable

[Chris Morrow]

Chris Morrow  added the comment:

oh crap :( I saw the 2.6 AFTER I posted the message :( sorry. grr, have 
to find a fix for 2.5 I suppose now.

Thanks.

___
Python tracker 

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

[issue1664] nntplib is not IPv6-capable

[Chris Morrow]

Chris Morrow  added the comment:

oy, and I'm not reading emails properly. I'll try the fix you propose 
for 2.5.

___
Python tracker 

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

[issue1664] nntplib is not IPv6-capable

[Chris Morrow]

Chris Morrow  added the comment:

a possible fix for 2.5 is:

morr...@tweezer:/tmp$ diff -U3 nntplib.py.orig nntplib.py
--- nntplib.py.orig 2008-12-30 01:06:14.0 -0500
+++ nntplib.py  2008-12-30 01:07:33.0 -0500
@@ -109,8 +109,19 @@
 """
 self.host = host
 self.port = port
-self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-self.sock.connect((self.host, self.port))
+msg = "getaddrinfo returns an empty list"
+for res in socket.getaddrinfo(self.host, self.port, 0, 
socket.SOCK_STREAM):
+  af, socktype, proto, canonname, sa = res
+  sock = None
+  try:
+self.sock = socket.socket(af, socktype, proto)
+self.sock.connect(sa)
+
+  except error, msg:
+if self.sock is not None:
+self.sock.close()
+raise NNTPError, msg
+
 self.file = self.sock.makefile('rb')
 self.debugging = 0
 self.welcome = self.getresp()


I'll open a bug against 2.5 now with this.

___
Python tracker 

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

[issue4777] nntplib - python 2.5

[Chris Morrow]

New submission from Chris Morrow :

nntplib.py on python2.5 is not IPv6 ready. The below patch at least 
makes connections on both ipv4 and ipv6 to servers.

This was taken out of bug: http://bugs.python.org/issue1664

if that helps...

platform: 
Linux hostnamehere 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 
2008 i686 i686 i386 GNU/Linux


morr...@tweezer:/tmp$ diff -U3 nntplib.py.orig nntplib.py
--- nntplib.py.orig 2008-12-30 01:06:14.0 -0500
+++ nntplib.py  2008-12-30 01:07:33.0 -0500
@@ -109,8 +109,19 @@
 """
 self.host = host
 self.port = port
-self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-self.sock.connect((self.host, self.port))
+msg = "getaddrinfo returns an empty list"
+for res in socket.getaddrinfo(self.host, self.port, 0, 
socket.SOCK_STREAM):
+  af, socktype, proto, canonname, sa = res
+  sock = None
+  try:
+self.sock = socket.socket(af, socktype, proto)
+self.sock.connect(sa)
+
+  except error, msg:
+if self.sock is not None:
+self.sock.close()
+raise NNTPError, msg
+
 self.file = self.sock.makefile('rb')
 self.debugging = 0
 self.welcome = self.getresp()

--
components: Library (Lib)
files: nntplib.py-ipv6.patch
keywords: patch
messages: 78509
nosy: morrowc
severity: normal
status: open
title: nntplib - python 2.5
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12489/nntplib.py-ipv6.patch

___
Python tracker 

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

[issue4750] tarfile keeps excessive dir structure in compressed files

[anatoly techtonik]

anatoly techtonik  added the comment:

I attach for Python 2.5 as well. People will use gzip module for a long
time to build packages and patch will help them to get correct archives.

Added file: http://bugs.python.org/file12490/python25.issue4750.diff

___
Python tracker 

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

[issue4701] range objects becomes hashable after attribute access

[Nick Coghlan]

Nick Coghlan  added the comment:

Forward port to 3.x:

3.1: r68058
3.0: r68060

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