[issue2574] Add RFC 3768 SSM Multicast support to "socket"

[Jean-Paul Calderone]

Changes by Jean-Paul Calderone :


--
keywords: +needs review
status: open -> languishing
versions: +Python 3.2 -Python 2.6

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

I agree that this should be landed (for 2.6 and 2.7).  I think I can do it.  I 
made some changes to the tests, though.  It would be nice for someone to look 
those over and make sure the change still looks good.

I checked everything in to the siginterrupt-reset-issue8354 branch.  You can 
also find the diff at http://codereview.appspot.com/1134042/show

--
versions: +Python 2.7

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Sreejith Madhavan]

Sreejith Madhavan  added the comment:

Attached a patch for Modules/zlibmodule.c that worked for me.  Tested with 
python (2.6.1 and 2.6.5) 64bit builds on Solaris (amd64 and sparc) and RHEL5.2 
amd64.

--
keywords: +patch
nosy: +Sreejith.Madhavan
Added file: http://bugs.python.org/file17243/zlibmodule.patch

___
Python tracker 

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

[issue8642] json.loads description

[MATSUI Tetsushi]

New submission from MATSUI Tetsushi :

At the end of description of json.loads, dump() should be load().

--
assignee: d...@python
components: Documentation
messages: 105187
nosy: d...@python, mft
priority: normal
severity: normal
status: open
title: json.loads description
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

[issue8610] Python3/POSIX: errors if file system encoding is None

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> "I think that using ASCII is a safer choice in case of errors. (...) Ouch, 
> that was a poor choice."
> 
> Ok, you conviced me with your PYTHONFSENCODING suggestion (#8622). Can you 
> review my last patch please?

I don't think we can change the fallback encoding in 3.2. But you
can start a discussion on python-dev, of course.

The number of Python 3.x users is still small, so perhaps it's still
possible to revert the choice and to use a safer default, which then
results in encoding errors that the user can see in form of tracebacks
rather than just by having actively checking the directory listing
for strange symbols.

Some comments on the patch:

+   fprintf(stderr,
+   "Unable to get the locale encoding: "
+   "fallback to utf-8\n");

This would have to read "... to ASCII"

+   Py_FileSystemDefaultEncoding = "ascii";

+   codec = _PyCodec_Lookup(Py_FileSystemDefaultEncoding);
+   if (!codec) {
+   Py_FatalError(
+   "Py_Initialize: unable to load the file system codec");

It's better to use the same approach as above for this situation
as well.

Fatal errors are just not user friendly and will likely cause
bad vibes towards Python3.

E.g.

fprintf(stderr,
"Unknown locale encoding: "
"fallback to ASCII\n");

You also need to change this line in pythonrun.c:

/* reset file system default encoding */
if (!Py_HasFileSystemDefaultEncoding) {
free((char*)Py_FileSystemDefaultEncoding);
Py_FileSystemDefaultEncoding = NULL;
}

I'm not sure what the purpose of Py_HasFileSystemDefaultEncoding
is. If we define a default for the file system encoding,
then why do we bother whether there is one ?

In any case, initfsencoding() would always have to set that
flag to 1.

--

___
Python tracker 

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

[issue8610] Python3/POSIX: errors if file system encoding is None

[STINNER Victor]

STINNER Victor  added the comment:

Le vendredi 07 mai 2010 11:19:52, vous avez écrit :
> > Ok, you conviced me with your PYTHONFSENCODING suggestion (#8622). Can
> > you review my last patch please?
> 
> I don't think we can change the fallback encoding in 3.2. But you
> can start a discussion on python-dev, of course.

Ok, I will ask on python-dev.

> + fprintf(stderr,
> + "Unable to get the locale encoding: "
> + "fallback to utf-8\n");
> 
> This would have to read "... to ASCII"

Fixed.

> 
> + Py_FileSystemDefaultEncoding = "ascii";
> 
> + codec = _PyCodec_Lookup(Py_FileSystemDefaultEncoding);
> + if (!codec) {
> + Py_FatalError(
> + "Py_Initialize: unable to load the file system codec");
> 
> It's better to use the same approach as above for this situation
> as well.

I choosed to display a fatal error here to give a more revelant error message 
to the user. Without the check, _PyCodec_Lookup() will fail anyway, but later 
in a random function :-/

The fatal error only occurs in critical situations: no more memory, import 
machinery completly broken (eg. #8611), etc. In this case, fallback to ASCII 
doesn't help, it will also raise somewhere later.

About nl_langinfo(CODESET): get_codeset() does already reject unknown 
encoding. So this call is only done on known encoding names.

> You also need to change this line in pythonrun.c:
> 
> /* reset file system default encoding */
> if (!Py_HasFileSystemDefaultEncoding) {
> free((char*)Py_FileSystemDefaultEncoding);
> Py_FileSystemDefaultEncoding = NULL;
> }

Fixed. This test only match if get_codeset() is used: I choosed to set the 
encoding to ASCII with Py_HasFileSystemDefaultEncoding=0.

> I'm not sure what the purpose of Py_HasFileSystemDefaultEncoding
> is.

Its name doesn't help. It's just a flag to tell if free() should be called or 
not... (see _Py_SetFileSystemEncoding()).

> In any case, initfsencoding() would always have to set that
> flag to 1.

initfsencoding() is a static function and it's only called by 
Py_InitializeEx(). Can Py_InitializeEx() be called multiple times?

--

___
Python tracker 

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

[issue8610] Python3/POSIX: errors if file system encoding is None

[STINNER Victor]

Changes by STINNER Victor :


Added file: http://bugs.python.org/file17244/initfsencoding-3.patch

___
Python tracker 

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

[issue8610] Python3/POSIX: errors if file system encoding is None

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file17242/initfsencoding-2.patch

___
Python tracker 

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

[issue8643] incorrect timedelta yielded by two on-the-fly nows

[Michal Božoň]

New submission from Michal Božoň :

now() - now() from datetime.datetime produces not-nearly-zero timedelta:

>>> import datetime
>>> (datetime.datetime.now() - datetime.datetime.now()).seconds
86399

(i can't in the moment figure out why this is happening, sice the datetime 
library is written in C)

--
components: Library (Lib)
messages: 105190
nosy: mykhal
priority: normal
severity: normal
status: open
title: incorrect timedelta yielded by two on-the-fly nows
type: behavior
versions: Python 2.5, Python 3.1

___
Python tracker 

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

[issue8638] Remove suggestion for name mangling from the tutorial

[Skip Montanaro]

Skip Montanaro  added the comment:

Maybe the wording should be changed, but name mangling serves a useful
purpose.  There are two definitions of "private" which seem to be a
bit conflated in this section:

* "private" as in, "this name is not part of the public API - use it
  at your own risk".

* "private" as in, "I don't want someone to accidentally stomp on this
  attribute name when subclassing this class".

I think it is valuable to mention both of these conventions in the
tutorial for a couple reasons:

* the tutorial is meant for people new to Python but with experience
  in other programming languages

* the distinction between _a and __a is a bit subtle and not obviously
  similar to privacy features present in other languages.

I work with a lot of C++ programmers who also write some Python
(sometimes a lot of Python).  It's clear at times that the distinction
hasn't always sunk in.

--
nosy: +skip.montanaro

___
Python tracker 

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

[issue8643] incorrect timedelta yielded by two on-the-fly nows subtraction

[Michal Božoň]

Changes by Michal Božoň :


--
title: incorrect timedelta yielded by two on-the-fly nows -> incorrect 
timedelta yielded by two on-the-fly nows subtraction

___
Python tracker 

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

[issue8643] incorrect timedelta yielded by two on-the-fly nows subtraction

[Mark Dickinson]

Mark Dickinson  added the comment:

This is correct behaviour.  Note that .seconds is only one of the three 
attributes that contribute to the value of a timedelta:  the others are 
.microseconds and .days.  A timedelta is normalised in such a way that 
td.seconds and td.microseconds are always nonnegative;  this means that td.days 
will be strictly negative for negative timedeltas.  In your case the timedelta 
will have a .days attribute of -1, and the total time represented (e.g., in 
seconds, 86400.0 * td.days + td.seconds + 0.01 * td.microseconds) will be 
small and negative.

Here's what I get on my system (in the py3k branch):

Python 3.2a0 (py3k:80840:80842, May  7 2010, 12:29:35) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> td = datetime.datetime.now() - datetime.datetime.now()
>>> td.microseconds, td.seconds, td.days
(998977, 86399, -1)
>>> print(td)
-1 day, 23:59:59.998977
>>> 1e-6 * td.microseconds + td.seconds + 86400 * td.days
-0.001023043520704
>>> td.total_seconds() # new in Python 2.7, 3.2
-0.001023043520704

--
nosy: +mark.dickinson
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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Confirmed. It even segfaults under 3.x.

--
nosy: +pitrou
priority: normal -> high
stage:  -> patch review
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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
versions: +Python 3.2

___
Python tracker 

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

[issue8643] incorrect timedelta yielded by two on-the-fly nows subtraction

[Michal Božoň]

Michal Božoň  added the comment:

ok, my fault, i should have tried

>>> (abs(datetime.datetime.now() - datetime.datetime.now())).seconds
0

sorry :)

--

___
Python tracker 

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

[issue8610] Python3/POSIX: errors if file system encoding is None

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
>> +codec = _PyCodec_Lookup(Py_FileSystemDefaultEncoding);
>> +if (!codec) {
>> +Py_FatalError(
>> +"Py_Initialize: unable to load the file system codec");
>>
>> It's better to use the same approach as above for this situation
>> as well.
> 
> I choosed to display a fatal error here to give a more revelant error message 
> to the user. Without the check, _PyCodec_Lookup() will fail anyway, but later 
> in a random function :-/
> 
> The fatal error only occurs in critical situations: no more memory, import 
> machinery completly broken (eg. #8611), etc. In this case, fallback to ASCII 
> doesn't help, it will also raise somewhere later.
> 
> About nl_langinfo(CODESET): get_codeset() does already reject unknown 
> encoding. So this call is only done on known encoding names.

Ok, please add a comment to that part explaining why it can only
fail as result of some other serious error and not because
the Py_FileSystemDefaultEncoding was not found to be supported
by Python.

>> I'm not sure what the purpose of Py_HasFileSystemDefaultEncoding
>> is.
> 
> Its name doesn't help. It's just a flag to tell if free() should be called or 
> not... (see _Py_SetFileSystemEncoding()).

Interesting... I would associate a completely different meaning
with it.

Scratch my comment on that flag then.

>> In any case, initfsencoding() would always have to set that
>> flag to 1.
> 
> initfsencoding() is a static function and it's only called by 
> Py_InitializeEx(). Can Py_InitializeEx() be called multiple times?

Well, it shouldn't be called multiple times, but then you never
know how embedded Python interpreters are used.

--

___
Python tracker 

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

[issue8643] incorrect timedelta yielded by two on-the-fly nows subtraction

[Mark Dickinson]

Mark Dickinson  added the comment:

Hmm.  My example did make me realize that the total_seconds() method isn't as 
accurate as it could be.  I'll open another issue for this.

--

___
Python tracker 

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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Mark Dickinson]

New submission from Mark Dickinson :

I just noticed (while responding to issue 8643) that timedelta.total_seconds() 
has some accuracy problems, especially for negative timedeltas:

Python 3.2a0 (py3k:80840:80842, May  7 2010, 12:29:35) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import timedelta
>>> td = timedelta(microseconds = -123)
>>> td.total_seconds() # expect -0.000123
-0.000123052601099

This could be easily fixed by using integer arithmetic internally instead of 
float arithmetic:

>>> 1e-6 * td.microseconds + td.seconds + 86400 * td.days
-0.000123052601099
>>> (td.microseconds + 100 * (td.seconds + 86400 * td.days)) / 100
-0.000123

This works especially nicely in combination with the new float repr and the 
improved accuracy of true division in 2.7 / 3.2, to give a total_seconds() 
whose repr is free of noise digits.  (Well, for small timedeltas, anyway.)

Since total_seconds is new in 2.7 and 3.2, I think it would be good to fix this 
before the 2.7 release.

--
components: Extension Modules
messages: 105197
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: timedelta.total_seconds needlessly inaccurate, especially for negative 
timedeltas
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Mark Dickinson]

Mark Dickinson  added the comment:

P.S.  This change would also make total_seconds() consistent with division by 
timedelta(seconds=1):

>>> td / timedelta(seconds=1)
-0.000123

In fact, this might even be a good way to re-implement total_seconds internally.

--

___
Python tracker 

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

[issue1533] Bug in range() function for large values

[Mark Dickinson]

Mark Dickinson  added the comment:

Yes, okay---that makes some sense;  I'm happy to leave floats as they are 
(i.e., DeprecationWarning for small floats; TypeError for larger floats) and 
just fix use of __int__ for non-floats.

I'll look at the patch.

--
assignee: belopolsky -> mark.dickinson

___
Python tracker 

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

[issue1533] Bug in range() function for large values

[Mark Dickinson]

Mark Dickinson  added the comment:

The backport looks fine.  Applied in r80917.  Thanks, Alexander.

--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8388] None shouldn't be passed to traceback.format_exception

[Michael Foord]

Michael Foord  added the comment:

Now fixed.

--
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8454] unittest Module Problem with different Kinds of Invocation

[Michael Foord]

Changes by Michael Foord :


--
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue8388] None shouldn't be passed to traceback.format_exception

[Michael Foord]

Michael Foord  added the comment:

Revision 80708 and revision 80709.

--

___
Python tracker 

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

[issue8645] PyUnicode_AsEncodedObject is undocumented

[Daniel Stutzbach]

New submission from Daniel Stutzbach :

PyUnicode_AsEncodedObject is undocumented.  It has the same signature as 
PyUnicode_AsEncodedString, although they do slightly different things based on 
a brief source code inspection (I'm not clear on what that difference is 
though).

--
assignee: d...@python
components: Documentation
messages: 105203
nosy: d...@python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_AsEncodedObject is undocumented
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch fixing the issue, and a similar one in compressobj.compress(). 
It also adds tests which are only enabled with the bigmem option.

--
Added file: http://bugs.python.org/file17245/zlibbigbuf.patch

___
Python tracker 

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

[issue8646] PyUnicode_EncodeDecimal is undocumented

[Daniel Stutzbach]

New submission from Daniel Stutzbach :

PyUnicode_EncodeDecimal is undocumented (although it's referenced in passing in 
the documentation for PyLong_FromUnicode).  There's a lengthy comment in 
unicodeobject.h describing PyUnicode_EncodeDecimal, which could be converted 
more or less directly into documentation.

--
assignee: d...@python
components: Documentation
messages: 105205
nosy: d...@python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_EncodeDecimal is undocumented
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue8647] PyUnicode_GetMax is undocumented

[Daniel Stutzbach]

New submission from Daniel Stutzbach :

Here's the relevant signature:

/* Get the maximum ordinal for a Unicode character. */
PyAPI_FUNC(Py_UNICODE) PyUnicode_GetMax(void);

--
assignee: d...@python
components: Documentation
messages: 105206
nosy: d...@python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_GetMax is undocumented
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue8648] The UTF-7 codec functions are undocumented

[Daniel Stutzbach]

New submission from Daniel Stutzbach :

The UTF-7 codec functions are undocumented:

PyUnicode_DecodeUTF7Stateful
PyUnicode_DecodeUTF7
PyUnicode_EncodeUTF7

--
assignee: d...@python
components: Documentation
messages: 105207
nosy: d...@python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: The UTF-7 codec functions are undocumented
versions: Python 2.6, Python 3.1

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Gregory P. Smith]

Gregory P. Smith  added the comment:

in the unittests there is some use of 'compress' and 'decompress'
mixed with 'zlib.decompress'.  which one is right (i'm only looking at
the diff so i can't see if they were imported from zlib or if the
zlib. is required at the moment).

otherwise, provided the new bigmem tests pass.  looks good to me.
commit and backport through to 2.6.

On Fri, May 7, 2010 at 8:56 AM, Antoine Pitrou  wrote:
>
> Antoine Pitrou  added the comment:
>
> Here is a patch fixing the issue, and a similar one in 
> compressobj.compress(). It also adds tests which are only enabled with the 
> bigmem option.
>
> --
> Added file: http://bugs.python.org/file17245/zlibbigbuf.patch
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am attaching a patch for py3k branch.  I am +1 for backporting to 2.7 and I 
avoided relying on py3k timedelta/timedelta in the patch.  The tests  and docs 
will need to be modified for the backport.

Technically speaking, this is a change in documented behavior for 2.7 because 
according to current docs, td.total_seconds() is equivalent to 
``td.microseconds / 100 + td.seconds + td.days * 24 * 3600``.  Therefore I 
would appreciate if reviewer made a decision on backport.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17246/issue8644-py3k.diff

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> in the unittests there is some use of 'compress' and 'decompress'
> mixed with 'zlib.decompress'.  which one is right

When testing the decompressor, data needs to be prepared first
(compressed). I didn't bother creating a compressor object in this case.

--

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Denis Dmitriev]

Denis Dmitriev  added the comment:

Is there a reason to keep inplen and max_length ints instead of making them 
Py_ssize_t too? I'm a little worried that keeping them ints will cause a 
similar problem further down the line.

--

___
Python tracker 

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

[issue8610] Python3/POSIX: errors if file system encoding is None

[STINNER Victor]

STINNER Victor  added the comment:

Version 4: I forgot #include  in bltinmodule.c.

--
Added file: http://bugs.python.org/file17247/initfsencoding-4.patch

___
Python tracker 

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

[issue8610] Python3/POSIX: errors if file system encoding is None

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file17244/initfsencoding-3.patch

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Is there a reason to keep inplen and max_length ints instead of making
> them Py_ssize_t too?

zlibmodule.c isn't 64-bit clean internally. Actually, the zlib itself
uses uInt in its z_stream structure. This should be the target of a
separate issue, and seems it will require more work than simply changing
the type of a variable.

--

___
Python tracker 

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

[issue8649] Py_UNICODE_* functions are undocumented

[Daniel Stutzbach]

New submission from Daniel Stutzbach :

Python provides several functions for manipulating raw Py_UNICODE strings, but 
they aren't documented.  Below are their signatures.

PyAPI_FUNC(size_t) Py_UNICODE_strlen(const Py_UNICODE *u);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strcpy(
Py_UNICODE *s1, const Py_UNICODE *s2);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strncpy(
Py_UNICODE *s1, const Py_UNICODE *s2, size_t n);

PyAPI_FUNC(int) Py_UNICODE_strcmp(
const Py_UNICODE *s1, const Py_UNICODE *s2);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strchr(
const Py_UNICODE *s, Py_UNICODE c
);

--
assignee: d...@python
components: Documentation
messages: 105214
nosy: d...@python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_UNICODE_* functions are undocumented
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue7900] posix.getgroups() failure on Mac OS X

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
stage: unit test needed -> patch review

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Patch committed in r80926 (trunk), r80927 (2.6), r80928 (py3k) and r80929 
(3.1). Thank you!

--

___
Python tracker 

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

[issue8571] zlib causes a SystemError when decompressing a chunk >1GB

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8650] zlibmodule.c isn't 64-bit clean

[Antoine Pitrou]

New submission from Antoine Pitrou :

zlibmodule.c doesn't define PY_SSIZE_T_CLEAN, and uses lots of "int" variables 
for length values internally.
Besides, the zlib itself uses "uInt" and "uLong" variables in its z_stream 
structure (rather than something guaranteed to be at least the width of a 
pointer).

On large input data, this will conspire to produce bogus results or crashes. 
For example:

>>> s = 'x' * (4 * 1024**3 + 100)
>>> t = zlib.compress(s, 1)
>>> len(t)
12
>>> len(zlib.decompress(t))
100

--
components: Extension Modules
messages: 105216
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: zlibmodule.c isn't 64-bit clean
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

[issue8650] zlibmodule.c isn't 64-bit clean

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +haypo

___
Python tracker 

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

[issue8651] "s#" and friends can silently truncate buffer length

[Antoine Pitrou]

New submission from Antoine Pitrou :

When PY_SSIZE_T isn't defined and a format such as "s#" receives an object 
whose length fits in a Py_ssize_t but not in an int, the buffer length is 
silently truncated:

>>> s = 'x' * (4 * 1024**3 + 100)
>>> t = zlib.compress(s, 1)
>>> len(t)
12
>>> len(zlib.decompress(t))
100

(from issue8650)

--
components: Interpreter Core
messages: 105217
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "s#" and friends can silently truncate buffer length
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

[issue8652] Minor improvements to the "Handling Exceptions" part of the tutorial

[Marien Zwart]

New submission from Marien Zwart :

Based on questions asked on freenode's #python by people reading the tutorial I 
would like to suggest two improvements to 
http://docs.python.org/tutorial/errors.html#handling-exceptions :

- Mention the older "except SomeException, e:" syntax too, not just "except 
SomeException as e:". I have had people ask me to help them upgrade to a newer 
python because they thought their version of python did not support catching 
exception instances (their distro python being 2.5). A big fat warning that 
they're reading the Python 2.6 tutorial (with links to older tutorials) may 
also work.

- Mention "except IOError as e" before mentioning "except IOError as (errno, 
strerror):". The latter is an advanced and relatively unusual trick, combining 
regular exception catching and unpacking. Those two concepts need to be 
explained before the combination is. I have had people ask me how to do "except 
KeyError as (key, insert_something_here):" because they thought they *always* 
needed those parens there.

(perhaps just not mentioning unpacking here at all, using "except IOError as 
e:" and then using e.errno would make more sense, especially since "except 
IOError as (errno, strerror):" is a SyntaxError in python 3 and up (because of 
the unpacking) and python 2.5.x and down (because of the "as")...)

I can try to write a patch to the documentation if you like.

--
assignee: d...@python
components: Documentation
messages: 105218
nosy: d...@python, marienz
priority: normal
severity: normal
status: open
title: Minor improvements to the "Handling Exceptions" part of the tutorial

___
Python tracker 

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

[issue8084] pep-0370 on osx duplicates existing functionality

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Christian hasn't been around for a while, and I'd like to release the next beta 
on time. Thus, I think Tarek's or my review will be sufficent. The idea seems 
fine to me.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue8547] unittest test discovery can fail when package under test is also installed globally

[Michael Foord]

Michael Foord  added the comment:

Committed revision 80932. Still needs documenting, so leaving open for the 
moment.

--

___
Python tracker 

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

[issue8653] urlparse.urlparse/urlsplit doc missing

[Dave Abrahams]

New submission from Dave Abrahams :

The docstrings for these functions don't explain the 'scheme' parameter.  Even 
renaming it to default_scheme would help.

--
assignee: d...@python
components: Documentation
messages: 105221
nosy: dabrahams, d...@python
priority: normal
severity: normal
status: open
title: urlparse.urlparse/urlsplit doc missing

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[Daniel Stutzbach]

New submission from Daniel Stutzbach :

Currently, Python can be built with an internal Unicode representation of UCS2 
or UCS4.  To prevent extension modules compiled with the wrong Unicode 
representation from linking, unicodeobject.h #defines many of the Unicode 
functions.  For example, PyUnicode_FromString becomes either 
PyUnicodeUCS2_FromString or PyUnicodeUCS4_FromString.

Consequently, if one installs a binary egg (e.g., with easy_install), there's a 
good chance one will get an error such as the following when trying to use it:

undefined symbol: PyUnicodeUCS2_FromString

In Python 2, only some extension modules were stung by this problem.  For 
Python 3, virtually every extension type will need to call a PyUnicode_* 
function, since __repr__ must return a Unicode object.  It's basically 
fruitless to upload a binary egg for Python 3 to PyPi, since it will generate 
link errors for a large fraction of downloaders (I discovered this the hard 
way).

Right now, nearly all the functions in unicodeobject.h are wrapped.  Several 
functions are not.  Many of the unwrapped functions also have no documentation, 
so I'm guessing they are newer functions that were not wrapped when they were 
added.

Most extensions treat PyUnicodeObjects as opaque and do not care if the 
internal representation is UCS2 or UCS4.  We can improve ABI compatibility by 
only wrapping functions where the representation matters from the caller's 
point of view.

For example, PyUnicode_FromUnicode creates a Unicode object from an array of 
Py_UNICODE objects.  It will interpret the data differently on UCS2 vs UCS4, so 
the function should be wrapped.

On the other hand, PyUnicode_FromString creates a Unicode object from a char *. 
 The caller can treat the returned object as opaque, so the function should not 
be wrapped.

The attached patch implements that rule.  It unwraps 64 opaque functions that 
were previously wrapped, and wraps 11 non-opaque functions that were previously 
unwrapped.  "make test" works with both UCS2 and UCS4 builds.

I previously brought this issue up on python-ideas, see:
http://mail.python.org/pipermail/python-ideas/2009-November/006543.html

Here's a summary of that discussion:

Zooko Wilcox-O'Hearn pointed out that my proposal is complimentary to his 
proposal to standardize on UCS4, to reduce the risk of extension modules built 
with a mismatched encoding.

Stefan Behnel pointed out that easy_install should allow eggs to specify the 
encoding they require.  PJE's proposed implementation of that feature 
(http://bit.ly/1bO62) would allow eggs to specify UCS2, UCS4, or "Don't Care".  
My proposal greatly increases the number of eggs that could label themselves 
"Don't Care", reducing maintenance work for package maintainers.  In other 
words, they are complimentary fixes.

Guido liked the idea but expressed concern about the possibility of extension 
modules that link successfully, but later crash because they actually do depend 
on the UCS2/UCS4 distinction.

With my current patch, there are still two ways for that to happen:

1) The extension uses only opaque functions, but casts the returned PyObject * 
to PyUnicodeObject * and accesses the str member, or

2) The extension uses only opaque functions, but uses the PyUnicode_AS_UNICODE 
or PyUnicode_AS_DATA macros.

Most packages that poke into the internals of PyUnicodeObject also call 
non-opaque functions.  Consequently, they will still generate a linker error if 
the encoding is mismatched, as desired.

I'm trying to come up with a way to 100% guarantee that any extension poking 
into the internals will generate a linker error if the encoding is mismatched, 
even if they don't call any non-opaque functions.  I'll post about that in a 
separate comment to this bug.

--
assignee: stutzbach
components: Interpreter Core, Unicode
messages: 105222
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve ABI compatibility between UCS2 and UCS4 builds
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[Daniel Stutzbach]

Changes by Daniel Stutzbach :


--
keywords: +patch
Added file: http://bugs.python.org/file17248/unicode.patch

___
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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

A question about the patch: in configure.in, after "if test 
$define_xopen_source = yes" (lines 395 and following), there's a bunch of 
Solaris-specific stuff. Shouldn't it be removed, given that _XOPEN_SOURCE isn't 
defined anymore under Solaris?

--
stage:  -> patch review
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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Forcing the compile-time and link-time encodings to match is tricky.  The goal 
is:

- Allow Unicode-agnostic modules to link, regardless of unicode settings
- Cause a link failure if the unicode settings are mismatched for a module that 
pokes into PyUnicodeObject

All of the solutions I've come up with have trade-offs.  Here is one approach:

Expose PyUnicodeObject if and only if the extension #defines a special flag 
(PY_EXPOSE_UNICODE_OBJECT?) before including Python.h.

If an extension does NOT define the flag, then PyUnicodeObject will not be 
defined nor the accessor macros for accessing its fields.  All of the opaque 
and non-opaque functions are still defined; the module just can't poke directly 
into PyUnicodeObject.  Linking will succeed as long as the module avoids 
non-opaque functions.

If the flag IS defined, then PyUnicodeObject will be defined along with the 
accessor macros.  The unicodeobject.h header will also arrange to require an 
appropriate symbol so that linking will succeed only if the module is compiled 
with the same Unicode settings as Python.

The upside of this approach is that it works: Unicode-agnostic modules will 
link and all others will not.

The drawback is a few extension modules will need to have a #define before 
including Python.h.  Only modules that poke into PyUnicodeObject will be 
impacted.  No change will be required for modules that depend on the Unicode 
setting yet stick to functions (opaque or not).

Thoughts?

--

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Adding people to the Nosy List who participated in the original thread on 
python-ideas, several months ago.  Hope you don't mind. :-)

--
nosy: +gvanrossum, scoder, zooko

___
Python tracker 

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

[issue7735] python creates IPv6 DNS requests even when built with --disable-ipv6

[Ralf Schmitt]

Changes by Ralf Schmitt :


--
nosy: +schmir

___
Python tracker 

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

[issue7735] python creates IPv6 DNS requests even when built with --disable-ipv6

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue8547] unittest test discovery can fail when package under test is also installed globally

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Reverted this in r80939. See 
http://python.org/dev/buildbot/stable/builders/x86%20XP-4%20trunk/builds/3553/steps/test/logs/stdio

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue8655] Problem with getpeercert in the ssl module when retrieving client side certs

[Westly Ward]

New submission from Westly Ward :

I originally had this problem when writing my IRCd, but then tested it in a 
basic script.  The problem is that getpeercert() is always returning None when 
executed on the server side, even when the client is using an ssl cert.  I have 
included an example in the attachment.  Just run sslserver.py in one terminal 
window, and then run sslclient.py in the other.  I also included the two fresh 
ssl certs and keys I used.  In client.txt and server.txt I put the commands I 
used to generate the ssl certs and keys.

--
components: Library (Lib)
files: ssltest.tar.gz
messages: 105227
nosy: Westly.Ward
priority: normal
severity: normal
status: open
title: Problem with getpeercert in the ssl module when retrieving client side 
certs
versions: Python 2.6
Added file: http://bugs.python.org/file17249/ssltest.tar.gz

___
Python tracker 

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

[issue4171] SSL handshake fails after TCP connection in getpeername()

[Dmitry Dvoinikov]

Dmitry Dvoinikov  added the comment:

Well, I'm sorry to bring this up again, but the problem persists
with Python 3.1.2 (x86, Windows XP). The difference with the
test script behaviour is that now it doesn't break every time.
Perhaps this is the reason I said the problem was gone.
In fact, now that I run the aforementioned script I may get

worked so far
but not here it didn't

and some other time I may get

worked so far
Traceback (most recent call last):
  File "test.py", line 23, in 
test_handshake(address, False)
  File "test.py", line 17, in test_handshake
ssl.do_handshake()
  File "C:\Python31\lib\ssl.py", line 327, in do_handshake
self._sslobj.do_handshake()
AttributeError: 'NoneType' object has no attribute 'do_handshake'

and the outcome is unpredictable. It may work many times in a row
and it may break many times in a row.

If this is of any relevance, I've had pywin32-2.14 installed since.

--
status: closed -> open

___
Python tracker 

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

[issue8655] Problem with getpeercert in the ssl module when retrieving client side certs

[Antoine Pitrou]

Antoine Pitrou  added the comment:

You must use either ssl.CERT_OPTIONAL or ssl.CERT_REQUIRED if you want to 
retrieve the client certificate. I admit this makes the getpeercert() API a bit 
strange, and I'm not sure why the original decision was made.

Can you confirm this fixes your issue?

--
nosy: +janssen, pitrou
resolution:  -> invalid
status: open -> pending

___
Python tracker 

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

[issue8655] Problem with getpeercert in the ssl module when retrieving client side certs

[Westly Ward]

Westly Ward  added the comment:

When I use the argument to make certs optional, it gave me an error saying it 
need the ca certs, so I downloaded them and specified to use them, and now I am 
getting errors from ssl.c

Here's the error on the server side:

wes...@westly-desktop ~/Desktop/ssltest $ python sslserver.py 
Traceback (most recent call last):
  File "sslserver.py", line 8, in 
conn, addr, = a.accept()
  File "/usr/lib/python2.6/ssl.py", line 326, in accept
suppress_ragged_eofs=self.suppress_ragged_eofs),
  File "/usr/lib/python2.6/ssl.py", line 118, in __init__
self.do_handshake()
  File "/usr/lib/python2.6/ssl.py", line 293, in do_handshake
self._sslobj.do_handshake()
SSLError: [Errno 1] _ssl.c:480: error:140890B2:SSL 
routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

Here's the error on the client side:

wes...@westly-desktop ~/Desktop/ssltest $ python sslclient.py 
Traceback (most recent call last):
  File "sslclient.py", line 4, in 
a.connect(("127.0.0.1", 112233))
  File "/usr/lib/python2.6/ssl.py", line 309, in connect
self.do_handshake()
  File "/usr/lib/python2.6/ssl.py", line 293, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:480: error:14094418:SSL 
routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

I got the ca certs from 
http://www.positivessl.com/ssl-certificate-support/cert_installation/UTN-USERFirst-Hardware.crt
 which is from a link the the ssl module docs.

I have attached the modified scripts.

--
status: pending -> open
Added file: http://bugs.python.org/file17250/ssltest.tar.gz

___
Python tracker 

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

[issue4171] SSL handshake fails after TCP connection in getpeername()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Are you able to compile a fresh checkout of either the py3k or release3.1-maint 
branch? A bunch of fixes have been committed recently, some of which may (or 
even should) address your issue.

--

___
Python tracker 

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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the patch!  Comments, in increasing order of fussiness:

(1) there should be a Py_DECREF(total_microseconds) in the case that the 
"PyLong_FromLong(100L)" call fails

(2) in the docstring, replace 'loose' by 'lose'

(3) also in the docstring, I suggest replacing "280 years" by "270 years":   
"td == timedelta(seconds = td.total_seconds())" starts failing at 2**33 seconds 
(around 272.2 Julian years) rather than 2**53 microseconds.

--

___
Python tracker 

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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Mark Dickinson]

Mark Dickinson  added the comment:

Grr.  s/docstring/docs/

--

___
Python tracker 

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

[issue1054967] bdist_deb - Debian packager

[Éric Araujo]

Éric Araujo  added the comment:

We forgot to reopen the bug.

--
status: closed -> open

___
Python tracker 

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

[issue8620] wrong truncation of last line in cmd.Cmd

[Éric Araujo]

Éric Araujo  added the comment:

Setting version to 3.2, since this change would not be backward compatible and 
2.7 is already in beta.

--
components: +Library (Lib) -None
nosy: +merwok
title: wrong truncation of line in Cmd.cmd -> wrong truncation of last line in 
cmd.Cmd
versions: +Python 3.2 -Python 2.6

___
Python tracker 

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

[issue8655] Problem with getpeercert in the ssl module when retrieving client side certs

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> When I use the argument to make certs optional, it gave me an error
> saying it need the ca certs, so I downloaded them and specified to use
> them, and now I am getting errors from ssl.c

You have to specify the CA cert corresponding to the Certificate
Authority (CA) who has signed your certificate.
A CA can be a company such as Verisign, etc.

However, in this case, you have self-signed the certificate; so the only
"CA cert" you can specify is the client certificate itself. If you
specify "client.crt" as the ca_certs argument, you'll see that it works.

--

___
Python tracker 

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

[issue8604] Adding an atomic FS write API

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

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

[issue8602] documentation of bz2 module mildly erroneous

[Éric Araujo]

Éric Araujo  added the comment:

Now that #8601 is closed, would you mind providing a doc patch explaining the 
lack of context manager protocol support and its reason?

--
nosy: +merwok

___
Python tracker 

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

Please don't. I've closed this bug because the bdist_deb command is currently 
managed by the stdeb project and it's fine like htis. Distutils2 will not have 
specialized linux bdist_* command like this one, because it is best to keep it 
in a separate project that can evolve as its own pace, in accordance with 
debian/ubuntu cycles.

--
status: open -> closed

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

I've been thinking about this a bit more.  There are three types of symbols in 
unicodeobject.h:

1. Functions that are always safe to use
2. Functions that are only safe if the module is compiled with the same Unicode 
settings as Python
3. Structures and macros that are only safe if the module is compiled with the 
same Unicode settings as Python

The functions in #2 will generate a link error if the module actually uses 
them.  

We can add some symbols next to the structures and macros (#3), such that there 
will always be a link error if the Unicode settings are mismatched.  However, 
we can't tell if the module actually uses the structure or not.

The hard question is: what should be declared by default?

Option 1: Make Unicode-agnosticism the default and force anyone who cares about 
the Unicode setting to include a separate header.  If they don't include that 
header, they can only call safe functions and can't poke at PyUnicodeObject's 
internals.  If they include the header, their module will always generate a 
link failure if the Unicode settings are mismatched.  (Guido proposed this 
solution in the python-ideas thread)

Option 2: Make Unicode-dependence the default.  If the compilation settings 
don't match, force a link failure.  Allow extension authors to define a flag 
(Py_UNICODE_AGNOSTIC) before including Python.h to avoid defining any unsafe 
functions, structures, or macros.  In practice, this is what Python 3 does 
today, except there's currently no way to declare Unicode-agnosticism.

Option 3: Go for a middle ground.  Modules are Unicode agnostic by default, 
unless they call a non-agnostic function (which will cause a link error if 
there's a mismatch).  If they want to poke directly into PyUnicodeObject, they 
still need to include a separate header.  I fear that this is the worst of both 
worlds, though.

The more I think about it, the more I like the first option.

Maybe I should bring this up on capi-sig and try to gather a consensus?

--

___
Python tracker 

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

[issue8638] Remove suggestion for name mangling from the tutorial

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Double underscore name mangling is for avoiding name clashes with base classes, 
not for 'private attributes'. This is such an advanced and rarely used feature 
that it hardly seems appropriate for the tutorial.

--
nosy: +tjreedy

___
Python tracker 

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

[issue8611] Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)

[STINNER Victor]

STINNER Victor  added the comment:

Let's try with something: pyunicode_asencodefsdefault.patch adds 
PyUnicode_EncodeFSDefault() function to uniformize how a unicode is converted 
to bytes. Fallback to UTF-8 if Py_FileSystemEncoding is not set (I should be 
ASCII, not UTF-8) and use surrogateescape error handler.

--
keywords: +patch
Added file: http://bugs.python.org/file17251/pyunicode_encodefsdefault.patch

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[R. David Murray]

R. David Murray  added the comment:

Adding MvL because he wrote the ABI PEP, and MAL because he cares about the 
Unicode interface.

--
nosy: +lemburg, loewis, r.david.murray

___
Python tracker 

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

[issue8638] Remove suggestion for name mangling from the tutorial

[Clovis Fabricio]

Clovis Fabricio  added the comment:

I help in #python and always suggest people to not use double-underscore name 
mangling when they mean private. 
I agree that name mangling shouldn't be on the tutorial at all. It misleads 
everybody coming from other languages into thinking that it means "private" 
like it does in java or C++.

--
nosy: +nosklo

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue8641] IDLE 3 doesn't highlights b"", but u""

[Terry J. Reedy]

Terry J. Reedy  added the comment:

u'whatever' is not valid syntax for 3.x.
In any case, with IDLE on my WinXP 3.1.2 system, all string literals are green, 
with or without a leading b.

If you want this to stay open, cut and paste the opening header like
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on 
win32
and some actual code and specify what you see and what you think is wrong.

--
nosy: +tjreedy
resolution:  -> works for me
status: open -> pending

___
Python tracker 

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

[issue8642] json.loads description

[Éric Araujo]

Éric Araujo  added the comment:

Is it possible for you to propose a patch, as described in 
http://www.python.org/dev/patches/ ?

--
nosy: +merwok

___
Python tracker 

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

[issue8547] unittest test discovery can fail when package under test is also installed globally

[Michael Foord]

Michael Foord  added the comment:

Committed again revision 80946 after getting the tests to pass on Windows.

--

___
Python tracker 

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

[issue8610] Python3/POSIX: errors if file system encoding is None

[STINNER Victor]

STINNER Victor  added the comment:

I realized that fallback to ASCII instead of UTF-8 is not possible yet because 
of #8611: if it fallbacks to ASCII, it's not more possible to run Python in a 
non-ASCII directory. I have a patch set fixing #8611 but it's huge and complex. 
I will not be fixed quickly (if it would be possible someday to fix it).

My new patch fallback to utf-8 instead of ascii, even if I agree that it would 
be better to fallback to ascii. Improve unicode, surrogates & friends is 
complex, and I prefer to fix bugs step by step. I propose to first ensure that 
Py_FileSystemEncoding is always set, and later write a new patch to fallback to 
ASCII instead of UTF-8.

Patch version 5:
 - fallback to utf-8 instead of ascii
 - Set Py_FileSystemDefaultEncoding to NULL to Py_Finalize(): thanks to that, 
it should be possible to call Py_InitializeEx() (initfsencoding()) twice or more
 - initfsencoding() doesn't call _PyCodec_Lookup() on get_codeset() success 
because  get_codeset() does already call it
 - explain that the fatal error is very unlikely

--
Added file: http://bugs.python.org/file17252/initfsencoding-5-utf-8.patch

___
Python tracker 

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

[issue8653] urlparse.urlparse/urlsplit doc missing

[Dan Buch]

Changes by Dan Buch :


--
nosy: +meatballhat

___
Python tracker 

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

[issue8602] documentation of bz2 module mildly erroneous

[Matt Wartell]

Matt Wartell  added the comment:

Per request, I have attached a context diff for both bz2.txt and 3.0.txt 
suitable for http://docs.python.org/library/bz2.html and 
http://docs.python.org/release/3.0.1/whatsnew/3.0.html respectively. 

The modification in bz2.txt may border on redundant and overly verbose and 
should be reviewed for style consistency.

I have sanity-checked the modified files with sphinx-build html which generates 
clean, consistent markup.

--
keywords: +patch
status: open -> pending
Added file: http://bugs.python.org/file17253/issue-8602.diff

___
Python tracker 

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

[issue8653] urlparse.urlparse/urlsplit doc missing

[Senthil Kumaran]

Senthil Kumaran  added the comment:

I don't see anything that is missing. Its here in the docs 
http://docs.python.org/library/urlparse.html#urlparse-result-object
And also docstrings has the information too.

Could you explain a bit more as what you were expecting and found missing?

--
assignee: d...@python -> orsenthil
nosy: +orsenthil

___
Python tracker 

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

[issue8656] urllib2 mangles file://-scheme URLs

[Dave Abrahams]

New submission from Dave Abrahams :

$ touch /tmp/x.html
$ python -c 'import urllib2;resp=urllib2.urlopen("file:///tmp/x.html");print 
resp.geturl()'
file:/tmp/x.html

note the missing // after the colon

--
messages: 105250
nosy: dabrahams
priority: normal
severity: normal
status: open
title: urllib2 mangles file://-scheme URLs
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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> (1) there should be a Py_DECREF(total_microseconds) ...

Yes, regrtest -R is not a substitute for thinking.

> (2) in the docstring, replace 'loose' by 'lose'
>

Neither is spellcheck. :-)

> (3) also in the docstring, I suggest replacing "280 years" by "270 years" ...

Yes, and precision is not accuracy.

--
Added file: http://bugs.python.org/file17254/issue8644-py3k.diff

___
Python tracker 

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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Removed file: http://bugs.python.org/file17246/issue8644-py3k.diff

___
Python tracker 

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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Added file: http://bugs.python.org/file17255/issue8644-py3k.diff

___
Python tracker 

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

[issue8644] timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Removed file: http://bugs.python.org/file17254/issue8644-py3k.diff

___
Python tracker 

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

[issue8642] json.loads description

[MATSUI Tetsushi]

MATSUI Tetsushi  added the comment:

OK, here you are.

--
keywords: +patch
Added file: http://bugs.python.org/file17256/json.diff

___
Python tracker 

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

[issue8657] urlparse.urlunsplit should be smarter about +

[Dave Abrahams]

New submission from Dave Abrahams :

from urlparse import *
urlunsplit(urlsplit('git+file:///foo/bar/baz'))
=> git+file:/foo/bar/baz

--
messages: 105253
nosy: dabrahams
priority: normal
severity: normal
status: open
title: urlparse.urlunsplit should be smarter about +
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

[issue8641] IDLE 3 doesn't highlights b"", but u""

[Puzzlet Chung]

Puzzlet Chung  added the comment:

> In any case, with IDLE on my WinXP 3.1.2 system, all string literals are 
> green, with or without a leading b.

The letter b should also be green, while it shows the letter u from u'string' 
in green, which it shouldn't as it's not valid anymore.

Tested in IDLE with following version of Python:

Python 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit (AMD64)] on 
win32

--
status: pending -> open

___
Python tracker 

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

[issue8656] urllib2 mangles file://-scheme URLs

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Fixed in r80953, r80954 , r80955 and r80956.

--
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue8658] urlparse.urlunsplit should be smarter about + and file urls

[Senthil Kumaran]

New submission from Senthil Kumaran :

>>> from urlparse import *
>>> urlsplit('git+file:///foo/bar/baz')
SplitResult(scheme='git+file', netloc='', path='/foo/bar/baz', query='', 
fragment='')
>>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
'git+file:/foo/bar/baz'
>>>

--
assignee: orsenthil
files: urlparse_giturl.patch
keywords: patch
messages: 105256
nosy: orsenthil
priority: normal
severity: normal
status: open
title: urlparse.urlunsplit should be smarter about + and file urls
type: behavior
Added file: http://bugs.python.org/file17257/urlparse_giturl.patch

___
Python tracker 

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

[issue8658] urlparse.urlunsplit should be smarter about + and file urls

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
nosy: +dabrahams

___
Python tracker 

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

[issue8657] urlparse.urlunsplit should be smarter about +

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
assignee:  -> orsenthil
keywords: +patch
nosy: +orsenthil
resolution:  -> accepted
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file17258/urlparse_giturl.patch

___
Python tracker 

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

[issue8658] urlparse.urlunsplit should be smarter about + and file urls

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Duplicate of Issue8657

--
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8656] urllib2 mangles file://-scheme URLs

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

Major buildbot failures caused by this change, eg:

ERROR: test_file (test.test_urllib2net.OtherNetworkTests)
--
Traceback (most recent call last):
  File 
"/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/test/test_urllib2net.py",
 line 126, in test_file
self._test_urls(urls, self._extra_handlers(), retry=True)
  File 
"/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/test/test_urllib2net.py",
 line 175, in _test_urls
f = urlopen(url, req, TIMEOUT)
  File 
"/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/test/test_urllib2net.py",
 line 28, in wrapped
return _retry_thrice(func, exc, *args, **kwargs)
  File 
"/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/test/test_urllib2net.py",
 line 19, in _retry_thrice
return func(*args, **kwargs)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", 
line 391, in open
response = self._open(req, data)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", 
line 409, in _open
'_open', req)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", 
line 369, in _call_chain
result = func(*args)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", 
line 1257, in file_open
return self.open_local_file(req)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", 
line 1291, in open_local_file
headers, 'file://'+ host + file)
TypeError: cannot concatenate 'str' and 'NoneType' objects

--
nosy: +exarkun

___
Python tracker 

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

[issue8656] urllib2 mangles file://-scheme URLs

[Senthil Kumaran]

Senthil Kumaran  added the comment:

On Sat, May 8, 2010 at 10:04 AM, Jean-Paul Calderone
 wrote:
> TypeError: cannot concatenate 'str' and 'NoneType' objects

Okay, I see where the problem is. I shall quickly fix it.

--

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[Zooko O'Whielacronx]

Zooko O'Whielacronx  added the comment:

> Option 1: Make Unicode-agnosticism the default and force anyone who cares 
> about the Unicode setting to include a separate header.  If they don't 
> include that header, they can only call safe functions and can't poke at 
> PyUnicodeObject's internals.  If they include the header, their module will 
> always generate a link failure if the Unicode settings are mismatched.  
> (Guido proposed this solution in the python-ideas thread)

+1

The packaging and compatibility problems are pressing concerns for many people. 
Poking at PyUnicodeObject's internals seems like a rare pretty rare need for an 
extension module to do. If I understand correctly, this option provides the 
best solution to the packaging and compatibility issues (over the long term, as 
Python and the authors of extension modules upgrade).

--

___
Python tracker 

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

[issue8638] Remove suggestion for name mangling from the tutorial

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

On Fri, May 7, 2010 at 6:35 PM, Terry J. Reedy  wrote:
> This is such an advanced and rarely used feature that it hardly seems 
> appropriate for the tutorial.

The problem with just leaving it out is that learners stumbling over
them in existing code (likely by trying to use something that looks
like it should be there and getting an AttributeError) won't have a
chance of knowing what the problem might be.

I'd be fine seeing new uses discouraged, especially for new learners,
but I think it's important that they be given a heads-up as well.

  -Fred

--
nosy: +fdrake

___
Python tracker 

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

[issue8513] subprocess: support bytes program name (POSIX)

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I think your partA patch makes sense.

It would benefit from fsencode/fsdecode functions rather than manually doing 
the 'surrogateescape' thing everywhere.

Also, could you add a unittest for os._execvpe to test its behavior?

--

___
Python tracker 

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