[issue1595365] Urllib2 user-agent header added by an opener is "frozen"

[Senthil Kumaran]

Senthil Kumaran  added the comment:

This is still a valid bug.

--
assignee:  -> orsenthil
resolution:  -> accepted
stage: unit test needed -> needs patch

___
Python tracker 

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

[issue1491] BaseHTTPServer incorrectly implements response code 100

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
assignee:  -> orsenthil

___
Python tracker 

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

[issue1172011] BaseCookie should call value_decode from __getitem__

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Moreover, BaseCookie should be used only for subclassing. Proper way is to 
always use SimpleCookie, this was an Invalid bug report.

--
stage: unit test needed -> committed/rejected

___
Python tracker 

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

[issue9864] email.utils.{parsedate, parsedate_tz} should have better return types

[R. David Murray]

R. David Murray  added the comment:

Yes, email6 should make use of datetime objects.  For email5 Antoine's proposal 
is better, but the question is will it happen before 3.2 beta :)

--

___
Python tracker 

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

[issue9917] resource max value represented as signed when should be unsigned

[R. David Murray]

New submission from R. David Murray :

Breaking out the library bug discussed in issue 678264 from the test bug the 
issue is about.

See msg14344 and msg116479.

--
components: Library (Lib)
messages: 117123
nosy: ajaksu2, loewis, mdr0, nnorwitz, r.david.murray, sable
priority: normal
severity: normal
stage: needs patch
status: open
title: resource max value represented as signed when should be unsigned
type: behavior
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

[issue678264] test_resource fails when file size is limited

[R. David Murray]

R. David Murray  added the comment:

That's what the original report is about, as opposed to the linux repr issue 
that Martin wants to break out into a new ticket (which I will do).  Any ideas 
how to fix the test?  It didn't fail for me on linux, so I don't have a good 
test platform for trying to fix it.

I'm un-assigning Neal since the original report is no longer the cause of the 
test error.  (The test has obviously changed since we don't check print output 
any more.)

--
assignee: nnorwitz -> 
components:  -Library (Lib)
nosy:  -BreamoreBoy
stage: unit test needed -> needs patch
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

[issue8998] add crypto routines to stdlib

[geremy condra]

geremy condra  added the comment:

>>> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
>>> is planning for an alpha release next month.
>>
>> Do you know if he's looking for help with that? There's been some talk of
>> a porting sprint here and I'd be happy to put that at the top of the list.
>
> I don't know. You might want to contact him directly.

Sent.

By the way, if you've used the keyphrene API and wouldn't mind sharing
how it compares with the proposed crypto API I'd appreciate it, I
don't think it came up in any of the initial conversations about this.

Geremy Condra

--

___
Python tracker 

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

[issue4661] email.parser: impossible to read messages encoded in a different encoding

[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

[issue4661] email.parser: impossible to read messages encoded in a different encoding

[R. David Murray]

R. David Murray  added the comment:

The 'str' around get_param shouldn't be there, that was left over from an 
earlier version of the patch.

I use surrogateescape rather than latin1 because using surrogateescape with 
ascii encoding gives me a reliable way to know whether or not the original 
source was bytes containing non-ascii chars.  (If it was bytes containing only 
ascii chars, then it doesn't matter what the original source was.)

--

___
Python tracker 

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

[issue4661] email.parser: impossible to read messages encoded in a different encoding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

A couple of comments:
- what is `str(self.get_param('charset', 'ascii'))` supposed to achieve? does 
get_param() return a bytes object?
- instead of ascii+surrogateescape, you could simply use latin1

--
nosy: +pitrou

___
Python tracker 

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

[issue4661] email.parser: impossible to read messages encoded in a different encoding

[R. David Murray]

R. David Murray  added the comment:

OK, I'm not entirely sure I want to post this, but

Antoine and I were having a conversation about nntplib and email and I noted 
that unicode as an email transmission channel acts as if it required 7bit clean 
data.  That is, that there's no way to use unicode as an 8bit data transmission 
channel.  Antoine pointed out that there is PEP 383, and that he is using that 
in his nntplib update to tunnel 8bit data (if there is any) from and back to 
the nntp server.  I said I couldn't do that with email because I not only 
needed to transmit the data, I also needed to *parse* it.

Antoine pointed out that you can in fact parse a header even if it has 
surrogateescape code points in it.

So I started thinking about that.  In point of fact, from the point of view of 
an email parser, non-ASCII bytes are pretty much opaque.  They don't affect the 
semantics of the parsing.  Either they are invalid data (in headers), or they 
are opaque content data (8bit Content-Transfer-Encoding).

So...I came up with a horrible little hack, which is attached here as a patch.  
This is horrible because it is a perversion of the Python3 desire to make a 
clean separation between bytes and strings.  The only thing it really has to 
recommend it is that it works: it allows email5 (the version of email currently 
in Python3) to read wire-format messages and parse them into valid message 
structures.

The patch is a proof of concept and is far from complete.  It handles only 
message bodies (but those are the most important) and has no doc updates and 
only one test.  If this approach is deemed worth considering, I will flesh out 
the tests and make sure the corner cases are handled correctly, and write docs 
with lots of notes about why this is perverse and email6 will make it all 
better :)

I feel bad about posting this both because it is an ugly hack and because it 
will likely slow down email6 development (because it will make email5 mostly 
work).  But making email5 mostly work in 3.2 seems like a case where 
practicality beats purity.

The essence of the hack is as follows: Given binary data we encode it to ASCII 
using the surrogateescape error handler.  Then, when a message body is 
retrieved we check to see if there are any surrogates in it, and if there are 
we encode it back to ASCII using surrogateescape, thereby recovering the 
original bytes.  For "Content-Transfer-Encoding: 8bit" parts we can then try to 
decode it using the declared charset, or ASCII with the replace error handler 
if the charset isn't known.  But in any case the original binary data is 
accessible by using 'decode=True' in the call to get_payload.  (NB for those 
not familiar with the API: decode=True refers to decoding the 
Content-Transfer-Encoding, *not* decoding to unicode...which means after CTE 
decoding you end up with a byte string).

For headers, which are not supposed to have 8bit data in them, the best we can 
do is re-decode them with ASCII/replace, but at least it will be possible to 
parse the messages.  (The current patch doesn't do this.)

Another thing missing from the current patch is the generator side.  But since 
the binary data for the message content is now available, it should be possible 
to have a generator that outputs binary.

Note that in this patch I've introduced new functions/methods for getting 
binary string data in, but for file input one needs to open the file as text 
using ASCII encoding and the surrogateescape error handler.

I've only done minimal testing on this (obviously), and so I may find a 
showstopper somewhere along the way, but so far it seems to work, and logically 
it seems like it should work.

I don't know if that makes me happy or sad :)

--
keywords: +patch
versions:  -Python 3.1
Added file: http://bugs.python.org/file18962/email_parse_bytes.diff

___
Python tracker 

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

[issue2193] Cookie Colon Name Bug

[John J Lee]

John J Lee  added the comment:

Looks like a bug.  Here's the trac bug that this caused -- trac fixed their bug 
by working around this bug in a really ugly way:

http://trac.edgewall.org/ticket/2256

It would be nice to notify the trac developers if/when this is fixed.

This bug is probably not specific to colons (e.g. commas used to be valid in 
HTTP cookie strings, and still are as far as I know -- somebody should test 
what current browsers do to make sure).  The set of characters regarded as 
legal is less important than the fact that parsing a Cookie header should 
*never* raise CookieError -- it should just ignore any invalid cookies.  Still, 
IIRC there isn't any need to treat any of them as invalid, since more or less 
anything is a valid cookie (or was in the past -- as I say, maybe browsers have 
cleaned up since then, but I'd be surprised).

--

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Eric Smith]

Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
Removed message: http://bugs.python.org/msg117111

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
Removed message: http://bugs.python.org/msg117110

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
Removed message: http://bugs.python.org/msg117106

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
Removed message: http://bugs.python.org/msg117107

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
Removed message: http://bugs.python.org/msg117108

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
Removed message: http://bugs.python.org/msg117109

___
Python tracker 

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

[issue9912] Fail when vsvarsall.bat produces stderr

[Floris Bruynooghe]

Floris Bruynooghe  added the comment:

msvc9_log.diff does log stderr at warning level when it occurs.

--
Added file: http://bugs.python.org/file18961/msvc9_log.diff

___
Python tracker 

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

[issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


Removed file: http://bugs.python.org/file18958/unnamed

___
Python tracker 

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

[issue9912] Fail when vsvarsall.bat produces stderr

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

yes, displaying the stderr content is a good idea.

--
stage:  -> needs patch

___
Python tracker 

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

[issue766910] fix one or two bugs in trace.py

[Mark Lawrence]

Mark Lawrence  added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger


From: Alexander Belopolsky 
To: breamore...@yahoo.co.uk
Sent: Tue, 21 September, 2010 19:35:10
Subject: [issue766910] fix one or two bugs in trace.py

Changes by Alexander Belopolsky :

--
assignee:  -> belopolsky
nosy: +belopolsky

___
Python tracker 

___

--
Added file: http://bugs.python.org/file18960/unnamed

___
Python tracker 

___Please ensure tha I'm taken off of the 
email list as I've been banned from contributing to Python by Raymond 
HettingerFrom: Alexander 
Belopolsky To: breamore...@yahoo.co.ukSent: Tue, 21 September, 2010 19:35:10Subject: [issue766910] fix one or two 
bugs in trace.pyChanges by Alexander Belopolsky belopol...@users.sourceforge.net>:--assignee: 
 -> belopolskynosy: 
+belopolsky___Python tracker 
rep...@bugs.python.org>http://bugs.python.org/issue766910>___




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

[issue766910] fix one or two bugs in trace.py

[Mark Lawrence]

Mark Lawrence  added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger


From: Alexander Belopolsky 
To: breamore...@yahoo.co.uk
Sent: Tue, 21 September, 2010 19:30:44
Subject: [issue766910] fix one or two bugs in trace.py

Changes by Alexander Belopolsky :

Removed file: http://bugs.python.org/file8481/unnamed

___
Python tracker 

___

--
Added file: http://bugs.python.org/file18959/unnamed

___
Python tracker 

___Please ensure tha I'm taken off of the 
email list as I've been banned from contributing to Python by Raymond 
HettingerFrom: Alexander 
Belopolsky To: breamore...@yahoo.co.ukSent: Tue, 21 September, 2010 19:30:44Subject: [issue766910] fix one or two 
bugs in trace.pyChanges by Alexander Belopolsky belopol...@users.sourceforge.net>:Removed
 file: http://bugs.python.org/file8481/unnamed"; 
target="_blank">http://bugs.python.org/file8481/unnamed___Python
 tracker rep...@bugs.python.org>http://bugs.python.org/issue766910>___




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

[issue9912] Fail when vsvarsall.bat produces stderr

[Floris Bruynooghe]

Floris Bruynooghe  added the comment:

I'm aware of that but my limited testing showed that in this case that doesn't 
happen.

However if this is considered too brittle to just plain fail as soon as there's 
stderr, how about using distutils' log facility to log the stderr at a 
reasonable level (warning?)?  That way at least you'll be able to see something 
useful when you get a failure at a strange looking and far less meaningful 
traceback a few lines lower.

--

___
Python tracker 

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

[issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions

[Mark Lawrence]

Mark Lawrence  added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger


From: Amaury Forgeot d'Arc 
To: breamore...@yahoo.co.uk
Sent: Tue, 21 September, 2010 18:56:51
Subject: [issue1962] ctypes feature request: Automatic type conversion of input 
arguments to C functions

Amaury Forgeot d'Arc  added the comment:

I don't think this should happen by default.
but what the user wants is already possible, by using the from_param() method.  
For example, the AutoStrParam type converts everything to a string (and a 
char*):

from ctypes import *

class AutoStrParam(c_char_p):
@classmethod
def from_param(cls, value):
return str(value)

strlen = cdll.LoadLibrary('msvcrt').strlen
strlen.argtypes = [AutoStrParam]

print strlen(None) # "None"  ->  4
print strlen(type) # "" -> 13

--
nosy: +amaury.forgeotdarc

___
Python tracker 

___

--
Added file: http://bugs.python.org/file18958/unnamed

___
Python tracker 

___Please ensure tha I'm taken off of the 
email list as I've been banned from contributing to Python by Raymond 
HettingerFrom: Amaury Forgeot 
d'Arc To: breamore...@yahoo.co.ukSent: Tue, 21 September, 2010 18:56:51Subject: [issue1962] ctypes feature 
request: Automatic type conversion of input arguments to C 
functionsAmaury Forgeot d'Arc amaur...@gmail.com> added the 
comment:I don't think this should happen by default.but what the 
user wants is already possible, by using the from_param() method.  For 
example, the AutoStrParam type converts everything to a string (and a 
char*):from ctypes import *class 
AutoStrParam(c_char_p):    @classmethod    def 
from_param(cls, value):        return 
str(value)strlen = cdll.LoadLibrary('msvcrt').strlenstrlen.argtypes 
= [AutoStrParam]print strlen(None)     # "None"    
      ->  4print strlen(type)     # 
"" -> 13--nosy: 
+amaury.forgeotdarc___Python 
tracker rep...@bugs.python.org>http://bugs.python.org/issue1962>___




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

[issue678250] test_mmap failling on AIX

[Mark Lawrence]

Mark Lawrence  added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger


From: Martin v. Löwis 
To: breamore...@yahoo.co.uk
Sent: Tue, 21 September, 2010 18:16:40
Subject: [issue678250] test_mmap failling on AIX

Martin v. Löwis  added the comment:

Looks fine to me.

--

___
Python tracker 

___

--
Added file: http://bugs.python.org/file18957/unnamed

___
Python tracker 

___Please ensure tha I'm taken off of the 
email list as I've been banned from contributing to Python by Raymond 
HettingerFrom: Martin v. Löwis 
To: breamore...@yahoo.co.ukSent: Tue, 21 September, 2010 18:16:40Subject: [issue678250] test_mmap failling 
on AIXMartin v. Löwis mar...@v.loewis.de> added the 
comment:Looks fine to 
me.--___Python 
tracker rep...@bugs.python.org>http://bugs.python.org/issue678250>___




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

[issue678250] test_mmap failling on AIX

[Mark Lawrence]

Mark Lawrence  added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger


From: Sébastien Sablé 
To: breamore...@yahoo.co.uk
Sent: Tue, 21 September, 2010 17:36:48
Subject: [issue678250] test_mmap failling on AIX

Sébastien Sablé  added the comment:

Would that patch be OK? It solves the test_mmap on AIX.

--
keywords: +patch
Added file: http://bugs.python.org/file18951/patch_flush_mmap.diff

___
Python tracker 

___

--
Added file: http://bugs.python.org/file18956/unnamed

___
Python tracker 

___Please ensure tha I'm taken off of the 
email list as I've been banned from contributing to Python by Raymond 
HettingerFrom: Sébastien Sablé 
To: breamore...@yahoo.co.ukSent: Tue, 21 September, 2010 17:36:48Subject: [issue678250] test_mmap failling 
on AIXSébastien Sablé sa...@users.sourceforge.net> 
added the comment:Would that patch be OK? It solves the test_mmap on 
AIX.--keywords: +patchAdded file: http://bugs.python.org/file18951/patch_flush_mmap.diff"; 
target="_blank">http://bugs.python.org/file18951/patch_flush_mmap.diff___Python
 tracker rep...@bugs.python.org>http://bugs.python.org/issue678250>___



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

[issue678250] test_mmap failling on AIX

[Mark Lawrence]

Mark Lawrence  added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger


From: Martin v. Löwis 
To: breamore...@yahoo.co.uk
Sent: Tue, 21 September, 2010 16:53:27
Subject: [issue678250] test_mmap failling on AIX

Martin v. Löwis  added the comment:

> Interestingly, the matter was discussed on another issue, #2643. I
> also agree that ideally flush() should become a no-op (only in 3.2,
> since it would break compatibility). But then we should also expose a
> separate sync() method with the current behaviour.

I think you misunderstand. I'm not proposing that flush should become
a noop entirely - only for ACCESS_COPY mappings.

--

___
Python tracker 

___

--
Added file: http://bugs.python.org/file18955/unnamed

___
Python tracker 

___Please ensure tha I'm taken off of the 
email list as I've been banned from contributing to Python by Raymond 
HettingerFrom: Martin v. Löwis 
To: breamore...@yahoo.co.ukSent: Tue, 21 September, 2010 16:53:27Subject: [issue678250] test_mmap failling 
on AIXMartin v. Löwis mar...@v.loewis.de> added the 
comment:> Interestingly, the matter was discussed on another issue, 
#2643. I> also agree that ideally flush() should become a no-op (only in 
3.2,> since it would break compatibility). But then we should also 
expose a> separate sync() method with the current behaviour.I 
think you misunderstand. I'm not proposing that flush should becomea noop 
entirely - only for ACCESS_COPY 
mappings.--___Python
 tracker rep...@bugs.python.org>http://bugs.python.org/issue678250>___




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

[issue678250] test_mmap failling on AIX

[Mark Lawrence]

Mark Lawrence  added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger


From: Antoine Pitrou 
To: breamore...@yahoo.co.uk
Sent: Tue, 21 September, 2010 16:43:19
Subject: [issue678250] test_mmap failling on AIX

Antoine Pitrou  added the comment:

Interestingly, the matter was discussed on another issue, #2643. I also agree 
that ideally flush() should become a no-op (only in 3.2, since it would break 
compatibility). But then we should also expose a separate sync() method with 
the 
current behaviour.

--
nosy: +pitrou

___
Python tracker 

___

--
Added file: http://bugs.python.org/file18954/unnamed

___
Python tracker 

___Please ensure tha I'm taken off of the 
email list as I've been banned from contributing to Python by Raymond 
HettingerFrom: Antoine Pitrou 
To: breamore...@yahoo.co.ukSent: Tue, 21 September, 2010 16:43:19Subject: [issue678250] test_mmap failling 
on AIXAntoine Pitrou pit...@free.fr> added the 
comment:Interestingly, the matter was discussed on another issue, 
#2643. I also agree that ideally flush() should become a no-op (only in 3.2, 
since it would break compatibility). But then we should also expose a separate 
sync() method with the current behaviour.--nosy: 
+pitrou___Python tracker rep...@bugs.python.org>http://bugs.python.org/issue678250>___




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

[issue678250] test_mmap failling on AIX

[Mark Lawrence]

Mark Lawrence  added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger


From: Martin v. Löwis 
To: breamore...@yahoo.co.uk
Sent: Tue, 21 September, 2010 16:28:06
Subject: [issue678250] test_mmap failling on AIX

Martin v. Löwis  added the comment:

> Should flush be modified to do nothing in this case or should the unit test 
> be 
>updated?

Tim is suggesting that flush should indeed become a noop. Since nobody
else speaking in favor of it being an error, I guess this is the way to
go: flush, on an ACCESS_COPY file, does nothing, and the test is fine
as it stands.

--

___
Python tracker 

___

--
Added file: http://bugs.python.org/file18953/unnamed

___
Python tracker 

___Please ensure tha I'm taken off of the 
email list as I've been banned from contributing to Python by Raymond 
HettingerFrom: Martin v. Löwis 
To: breamore...@yahoo.co.ukSent: Tue, 21 September, 2010 16:28:06Subject: [issue678250] test_mmap failling 
on AIXMartin v. Löwis mar...@v.loewis.de> added the 
comment:> Should flush be modified to do nothing in this case or 
should the unit test be updated?Tim is suggesting that flush should 
indeed become a noop. Since nobodyelse speaking in favor of it being an 
error, I guess this is the way togo: flush, on an ACCESS_COPY file, does 
nothing, and the test is fineas it 
stands.--___Python
 tracker rep...@bugs.python.org>http://bugs.python.org/issue678250>___




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

[issue9916] errno module is missing some symbols

[Barry A. Warsaw]

New submission from Barry A. Warsaw :

According to this message, Python's errno module is missing some symbols:

https://lists.ubuntu.com/archives/ubuntu-devel/2010-August/031341.html

ENOMEDIUM   123 /* No medium found */
EMEDIUMTYPE 124 /* Wrong medium type */
ECANCELED   125 /* Operation Canceled */
ENOKEY  126 /* Required key not available */
EKEYEXPIRED 127 /* Key has expired */
EKEYREVOKED 128 /* Key has been revoked */
EKEYREJECTED129 /* Key was rejected by service */
EOWNERDEAD  130 /* Owner died */
ENOTRECOVERABLE 131 /* State not recoverable */
ERFKILL 132 /* Operation not possible due to RF-kill */

While we're at it, it might be nice to add -m functionality to print out the 
errno, though I'm not even sure this is possible with an extension module.

--
assignee: barry
components: Extension Modules
messages: 117105
nosy: barry
priority: normal
severity: normal
status: open
title: errno module is missing some symbols
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

[issue9915] speeding up sorting with a key

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Antoine said:
> I don't think there's any point in micro-optimizations such as
> stack_keys.

Good point.  I'll try taking that out and see how it impacts the timing.

Raymond said:
> The memmove, memcpy functions are tricky to time because of varying
> performance across various architectures and libraries.  Code like
> "*dest++ = *pb++;" is hard to beat, especially for short runs.

Anything that was a memmove or memcpy remains a memmove or memcpy.  Anything 
that was equivalent but implemented "by hand" remains that way. (Although in 
either case the details have been moved into a sortslice_* static inline 
function.) 

I have avoided changing any memcpy/memmove to "by hand" (or vise versa), 
because I know that it might be faster on my system but slower on someone 
else's.

> Is the code slower for the common case where a key function is not
> provided?  

The short answer is "no".  The long answer is that I conducted enough 
experiments for the 95% confidence interval of the ratio of execution times 
(patched/trunk) to be 0.994735131656 +/- 0.00540792612332, for the case where 
no key function is provided.

> The patch seems to add a level of indirection throughout the code
> (lots of "lo.values" instead of just "lo").

The compiler can exactly compute the stack offset of "lo.values", so it should 
require the same number and type of instructions to access as just "lo".

> A more extensive timing suite would be helpful; the ones listed in 
> the first post are simplistic.

I have one, but it's clunky and requires modifying the script to change 
important parameters.  I'm refactoring it to use argparse and will attach it to 
this issue when it's ready.

--

___
Python tracker 

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

[issue1660009] continuing problem with httplib multiple set-cookie headers

[John J Lee]

John J Lee  added the comment:

What I said in 2007 re commas could be well out of date (might well have been 
so even then, in fact).  Somebody should check what browsers do now...

--

___
Python tracker 

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

[issue9325] Add an option to pdb/trace/profile to run library module as a script

[Nick Coghlan]

Nick Coghlan  added the comment:

I've thought about this in the past, but never really pursued it due to the 
question of what to do with the __main__ namespace.

There are three options here:
1. Use runpy.run_module to run the module in a fresh __main__ namespace
2. Use runpy.run_module to run the module under its own name
3. Use runpy._run_module_as_main to run the module in the real __main__ 
namespace

Option 3 is probably a bad idea (due to the risk of clobbering globals from 
pdb/trace/profile/doctest/etc) but failing to do it that way creates a 
difference between the way the actual -m switch works and what these modules 
will be doing.

That said, I haven't looked closely at what these modules do for ordinary 
scripts, where much the same problem will already arise. If option 1 is 
adequate for this purpose, then it shouldn't be that hard to add - it's just 
that I've never done the investigation to see if it *would* be adequate.

--

___
Python tracker 

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

[issue8998] add crypto routines to stdlib

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

geremy condra wrote:
> 
>>> The intention all along has been that we use the C API, and in fact
>>> I'm pretty far along on writing that. Assuming there won't be an issue
>>> with porting pyopenssl to python3, this seems like a pretty good idea
>>> to me though.
>>
>> Ah, sorry, I must have missed that turn in the discussion :-)
>>
>> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
>> is planning for an alpha release next month.
> 
> Do you know if he's looking for help with that? There's been some talk of
> a porting sprint here and I'd be happy to put that at the top of the list.

I don't know. You might want to contact him directly.

--

___
Python tracker 

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

[issue9131] test_set_reprs in test_pprint is fragile

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Committed in r84961

--
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior
versions:  -Python 3.3

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Conceptually, this is a reasonable approach.  

I originally put in the sortwrapper as a straight-forward technique of tackling 
the 2.x API which allowed a key-function, or a cmp-function, or both, or 
neither.   IOW, the original motivation is now gone.  The only remaining 
advantage of the sortwrapper is that it is independent of the main code for the 
timsort, so both are more readable and maintainable in their current form.

I've only had a cursory look at the patch.  A couple of thoughts:

* The memmove, memcpy functions are tricky to time because of varying 
performance across various architectures and libraries.  Code like "*dest++ = 
*pb++;" is hard to beat, especially for short runs.

* Is the code slower for the common case where a key function is not provided?  
The patch seems to add a level of indirection throughout the code (lots of 
"lo.values" instead of just "lo").

* A more extensive timing suite would be helpful; the ones listed in the first 
post are simplistic.

--

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Looks rather nice. I don't think there's any point in micro-optimizations such 
as stack_keys.

--
nosy: +pitrou

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Daniel Stutzbach]

New submission from Daniel Stutzbach :

(I've made an educated guess about who to add to the Nosy list)

The attached patch substantially speeds up sorting using the "key" parameter.  
It is purely a performance patch; the language and libraries are not changed in 
any other way from the users point of view.  I measured a reduction in 
execution time of at least 15% in many cases and more than 40% for large n.

I performed measurements on an Intel 64-bit Linux system using gcc 4.3.2 and on 
an Intel 32-bit Windows XP system using Visual C Express Edition 2009.

Previously, "key" was implemented by a creating a sortwrapperobject, which is a 
PyObject storing a key and a value and using only the key for comparison.  

With the patch, sortwrapperobject is removed entirely.  Instead, the sort uses 
two arrays: one for keys and one for values.  Comparisons use the keys array.  
Whenever a swap is performed, the swap is performed on both arrays.  If the 
"keys" parameter is not provided to the sort, the second swap is skipped (since 
the keys are also the values).

Compared to the sortwrapperobject approach, speed is improved by:
- Requiring only 1 memory allocation for an array of PyObject *'s, instead of n 
memory allocations for n sortwrapperobjects
- Removes the need to dereference through sortwrapperobjects, which were 
scattered about in memory (i.e., had poor cache locality)
- Substantially smaller memory overhead, further improving cache performance
 
When the "key" parameter is not used, the code still needs to check to see if 
it should be performing a second swap.  However, the additional instructions 
are cache and branch-prediction friendly and do not have a noticeable impact on 
performance.  I conducted enough experiments to establish a 95% confidence 
interval that excluded a slowdown of more than 1% (but did not exclude a 
slowdown of 0% - which is good).

A handful of results:

# No key, same speed
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 
'f()'
100 loops, best of 3: 0.276 usec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f()' 
100 loops, best of 3: 0.276 usec per loop

# With a key, patched version is faster
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 
'f(key=int)'
100 loops, best of 3: 1.76 usec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 
'f(key=int)'
100 loops, best of 3: 1.5 usec per loop

# Results are more dramatic with large n
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(10))' -s 'f = 
x.sort' 'f(key=int)'
10 loops, best of 3: 35.2 msec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(10))' -s 'f = x.sort' 
'f(key=int)'
10 loops, best of 3: 22.4 msec per loop

I have been using a script for running a large battery of experiments with 
different values of n and different conditions (random data, sorted data, 
reverse-sorted data, key, no key, etc.).  The script works, but it's clunky to 
use.  I'm working on cleaning that up and hope to attach it to this issue 
within the next few days.

--
assignee: stutzbach
components: Library (Lib)
files: sort-key-locality.diff
keywords: patch
messages: 117097
nosy: collinwinter, rhettinger, stutzbach, tim_one
priority: normal
severity: normal
stage: patch review
status: open
title: speeding up sorting with a key
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18952/sort-key-locality.diff

___
Python tracker 

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

[issue9899] tkinter test_font fails on OS X with Aqua Tk

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
status: pending -> closed

___
Python tracker 

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

[issue9860] Building python outside of source directory fails

[Ned Deily]

Ned Deily  added the comment:

FYIW, the OS X installer build script (Mac/BuildScript/build-installer.py for 
years has, and continues to, depend on building outside of the source 
directory.  When I build one, I always start with a clean source directory.  
There are so many opportunities for the configure and make stages to go wrong 
that it seems not worth the effort to try to plug all of the holes of the type 
you have identified here when attempting to build with a "dirty" source 
directory.  I wouldn't trust using one.

--
nosy: +ned.deily

___
Python tracker 

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

[issue9621] Graphviz output for 2to3 fixer patterns

[Matt Bond]

Matt Bond  added the comment:

Éric,

When I was working with 2to3 this summer I was running it via python3, so I 
think the patch should work - however, if I've submitted it to the wrong place 
or the wrong branch, where should I be looking at to ensure my code does work 
on 3.2 and is submitted to the right place?

In regard to the import gvgraph, I wasn't sure what to do with it - for my 
distribution gvgraph wasn't available as a package, and it was only one file so 
I just dumped it in the same directory as the script. I'm open to suggestions 
as to how that import should be handled better.

Alexander - I'll attach a sample image as soon as I get back to my development 
machine, which should be later this week.

--

___
Python tracker 

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

[issue9906] including elementary mathematical functions in default types

[Raymond Hettinger]

Changes by Raymond Hettinger :


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

[issue8998] add crypto routines to stdlib

[geremy condra]

geremy condra  added the comment:

On Tue, Sep 21, 2010 at 11:29 AM, Marc-Andre Lemburg
 wrote:
>
> Marc-Andre Lemburg  added the comment:
>
> geremy condra wrote:
>>
> I'll ask Jean-Paul and AB Strakt if they are up to contributing
> the pyOpenSSL code to the Python stdlib based on a contributor
> agreement. This would enable us to relicense the code under
> the PSF license even if the original code's license is not
> changed.
>
> Once that's a done deal, we can then consider moving in the above
> direction.

 I'm not sure I understand the relevance of pyopenssl here- it's pretty
 clearly focused on SSL/TLS rather than on crypto. Maybe someone can
 clarify?
>>>
>>> Yes, but it provides a decent platform for adding other crypto APIs
>>> as well and then we could have these as C APIs rather than wrappers
>>> using ctypes.
>>
>> The intention all along has been that we use the C API, and in fact
>> I'm pretty far along on writing that. Assuming there won't be an issue
>> with porting pyopenssl to python3, this seems like a pretty good idea
>> to me though.
>
> Ah, sorry, I must have missed that turn in the discussion :-)
>
> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
> is planning for an alpha release next month.

Do you know if he's looking for help with that? There's been some talk of
a porting sprint here and I'd be happy to put that at the top of the list.

>>> There's already a patch available from Keyphrene adding all those bits:
>>> http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en
>>>
>>> The patch would need to be updated for the new pyOpenSSL version,
>>> but that's certainly within range. And we'd need to get their permission
>>> to relicense as well.
>>
>> Bits and pieces of this look useful but it also looks like I'd be
>> rewriting a lot of it to move away from the RSA_* routines, etc. I
>> suspect it would take more time to get it into line than to just
>> cherrypick out of it.
>
> If you are writing new code for this anyway, it may be better to
> avoid the license question of the Keyphrene patch and just use
> their code as reference.

Yeah, I think that makes the most sense.

Geremy Condra

--

___
Python tracker 

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

[issue9325] Add an option to pdb/trace/profile to run library module as a script

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +ncoghlan, terry.reedy

___
Python tracker 

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

[issue9552] ssl build under Windows always rebuilds OpenSSL

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

I committed py3k_openssl.patch in r84957(py3k).
I won't merge into release27-maint nor release31-maint
because they are built against openssl-0.9.x and
don't have *.asm copy code.

--

___
Python tracker 

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

[issue766910] fix one or two bugs in trace.py

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
assignee:  -> belopolsky
nosy: +belopolsky

___
Python tracker 

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

[issue766910] fix one or two bugs in trace.py

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Removed file: http://bugs.python.org/file8481/unnamed

___
Python tracker 

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

[issue8998] add crypto routines to stdlib

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

geremy condra wrote:
> 
 I'll ask Jean-Paul and AB Strakt if they are up to contributing
 the pyOpenSSL code to the Python stdlib based on a contributor
 agreement. This would enable us to relicense the code under
 the PSF license even if the original code's license is not
 changed.

 Once that's a done deal, we can then consider moving in the above
 direction.
>>>
>>> I'm not sure I understand the relevance of pyopenssl here- it's pretty
>>> clearly focused on SSL/TLS rather than on crypto. Maybe someone can
>>> clarify?
>>
>> Yes, but it provides a decent platform for adding other crypto APIs
>> as well and then we could have these as C APIs rather than wrappers
>> using ctypes.
> 
> The intention all along has been that we use the C API, and in fact
> I'm pretty far along on writing that. Assuming there won't be an issue
> with porting pyopenssl to python3, this seems like a pretty good idea
> to me though.

Ah, sorry, I must have missed that turn in the discussion :-)

The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
is planning for an alpha release next month.

>> There's already a patch available from Keyphrene adding all those bits:
>> http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en
>>
>> The patch would need to be updated for the new pyOpenSSL version,
>> but that's certainly within range. And we'd need to get their permission
>> to relicense as well.
> 
> Bits and pieces of this look useful but it also looks like I'd be
> rewriting a lot of it to move away from the RSA_* routines, etc. I
> suspect it would take more time to get it into line than to just
> cherrypick out of it.

If you are writing new code for this anyway, it may be better to
avoid the license question of the Keyphrene patch and just use
their code as reference.

--

___
Python tracker 

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

[issue9908] os.stat() fails on bytes paths under Windows 7

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, I committed the patch in r84956. Thank you for testing.

--
resolution:  -> fixed
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

[issue9914] trace/profile conflict with the use of sys.modules[__name__]

[Alexander Belopolsky]

New submission from Alexander Belopolsky :

The main() method of trace and profile modules attempt to emulate the 
environment in which traced code runs when invoked directly, but it fails in 
several respects.   The specific problem which is the subject of this issue is 
that while __name__ is set to '__main__' in code globals, 
sys.modules['__main__'] still point to the trace/profile module.

Among other problems, this conflicts, with a popular idiom used in regression 
test scripts:

   support.run_unittest(__name__)

For example,

$ python -m trace -c -C trace.d Lib/test/test_optparse.py 

--
Ran 0 tests in 0.001s

OK

No tests are ran because run_unittests() looks for test case classes in the 
trace module and finds none.


This is related to #9323, so I am merging in the nosy list.  See also r83393.

--
assignee: belopolsky
components: Library (Lib)
messages: 117090
nosy: belopolsky, eli.bendersky, ezio.melotti, flox, georg.brandl
priority: normal
severity: normal
status: open
title: trace/profile conflict with the use of sys.modules[__name__]
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

[issue8998] add crypto routines to stdlib

[geremy condra]

geremy condra  added the comment:

On Tue, Sep 21, 2010 at 10:33 AM, Marc-Andre Lemburg
 wrote:
>
> Marc-Andre Lemburg  added the comment:
>
> geremy condra wrote:
>>
>> geremy condra  added the comment:
>>
>> On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
>>  wrote:
>>>
>>> Marc-Andre Lemburg  added the comment:
>>>
>>> Antoine Pitrou wrote:

 Antoine Pitrou  added the comment:

> pyOpenSSL is stable, in production use and
> has a decent API. The ssl module is good enough for HTTPS client
> use. pyOpenSSL provides a robust server side implementation with
> all the required certificate and context handling needed for this.
>
> We could tell people to use the ssl module for clients and
> pyOpenSSL for the server side and perhaps integrate the OpenSSL
> package into the ssl namespace.

 In this case, this should be decided early, so that I know if I should
 continue caring about the ssl module or not. I'm not interested in
 maintaining potentially obsolete code.
>>>
>>> I'll ask Jean-Paul and AB Strakt if they are up to contributing
>>> the pyOpenSSL code to the Python stdlib based on a contributor
>>> agreement. This would enable us to relicense the code under
>>> the PSF license even if the original code's license is not
>>> changed.
>>>
>>> Once that's a done deal, we can then consider moving in the above
>>> direction.
>>
>> I'm not sure I understand the relevance of pyopenssl here- it's pretty
>> clearly focused on SSL/TLS rather than on crypto. Maybe someone can
>> clarify?
>
> Yes, but it provides a decent platform for adding other crypto APIs
> as well and then we could have these as C APIs rather than wrappers
> using ctypes.

The intention all along has been that we use the C API, and in fact
I'm pretty far along on writing that. Assuming there won't be an issue
with porting pyopenssl to python3, this seems like a pretty good idea
to me though.

> There's already a patch available from Keyphrene adding all those bits:
> http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en
>
> The patch would need to be updated for the new pyOpenSSL version,
> but that's certainly within range. And we'd need to get their permission
> to relicense as well.

Bits and pieces of this look useful but it also looks like I'd be
rewriting a lot of it to move away from the RSA_* routines, etc. I
suspect it would take more time to get it into line than to just
cherrypick out of it.

Geremy Condra

--

___
Python tracker 

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

[issue9908] os.stat() fails on bytes paths under Windows 7

[Brian Curtin]

Brian Curtin  added the comment:

The patch looks ok to me. I tested it on Server 2003 (same as XP) and it worked 
fine in addition to Windows 7.

--

___
Python tracker 

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

[issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

I don't think this should happen by default.
but what the user wants is already possible, by using the from_param() method.  
For example, the AutoStrParam type converts everything to a string (and a 
char*):

from ctypes import *

class AutoStrParam(c_char_p):
@classmethod
def from_param(cls, value):
return str(value)

strlen = cdll.LoadLibrary('msvcrt').strlen
strlen.argtypes = [AutoStrParam]

print strlen(None) # "None"  ->  4
print strlen(type) # "" -> 13

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue8998] add crypto routines to stdlib

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

geremy condra wrote:
> 
> geremy condra  added the comment:
> 
> On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
>  wrote:
>>
>> Marc-Andre Lemburg  added the comment:
>>
>> Antoine Pitrou wrote:
>>>
>>> Antoine Pitrou  added the comment:
>>>
 pyOpenSSL is stable, in production use and
 has a decent API. The ssl module is good enough for HTTPS client
 use. pyOpenSSL provides a robust server side implementation with
 all the required certificate and context handling needed for this.

 We could tell people to use the ssl module for clients and
 pyOpenSSL for the server side and perhaps integrate the OpenSSL
 package into the ssl namespace.
>>>
>>> In this case, this should be decided early, so that I know if I should
>>> continue caring about the ssl module or not. I'm not interested in
>>> maintaining potentially obsolete code.
>>
>> I'll ask Jean-Paul and AB Strakt if they are up to contributing
>> the pyOpenSSL code to the Python stdlib based on a contributor
>> agreement. This would enable us to relicense the code under
>> the PSF license even if the original code's license is not
>> changed.
>>
>> Once that's a done deal, we can then consider moving in the above
>> direction.
> 
> I'm not sure I understand the relevance of pyopenssl here- it's pretty
> clearly focused on SSL/TLS rather than on crypto. Maybe someone can
> clarify?

Yes, but it provides a decent platform for adding other crypto APIs
as well and then we could have these as C APIs rather than wrappers
using ctypes.

There's already a patch available from Keyphrene adding all those bits:
http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en

The patch would need to be updated for the new pyOpenSSL version,
but that's certainly within range. And we'd need to get their permission
to relicense as well.

--

___
Python tracker 

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

[issue9119] Python download page needs to mention crypto code in Windows installer

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I sent an email.

--

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Looks fine to me.

--

___
Python tracker 

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

[issue9908] os.stat() fails on bytes paths under Windows 7

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Only if given a revised 32bit binary (and revised test_os.py). I expect someone 
else who can will see this.

--

___
Python tracker 

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

[issue9912] Fail when vsvarsall.bat produces stderr

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

A non-empty stderr does not mean that a command failed.
For example, the Microsoft compiler "cl.exe" prints the version string to 
stderr.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Would that patch be OK? It solves the test_mmap on AIX.

--
keywords: +patch
Added file: http://bugs.python.org/file18951/patch_flush_mmap.diff

___
Python tracker 

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

[issue9899] tkinter test_font fails on OS X with Aqua Tk

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Patch committed in r84952. Thanks!

--
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> pending

___
Python tracker 

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

[issue2643] mmap_object_dealloc calls time-consuming msync(), although close doesn't

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue2643] mmap_object_dealloc calls time-consuming msync(), although close doesn't

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I agree that calling msync on close/dealloc is not really necessary.
> The Windows version doesn't sync, either.

Ok, thank you. I committed the patch in r84950.

--

___
Python tracker 

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

[issue8998] add crypto routines to stdlib

[geremy condra]

geremy condra  added the comment:

On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
 wrote:
>
> Marc-Andre Lemburg  added the comment:
>
> Antoine Pitrou wrote:
>>
>> Antoine Pitrou  added the comment:
>>
>>> pyOpenSSL is stable, in production use and
>>> has a decent API. The ssl module is good enough for HTTPS client
>>> use. pyOpenSSL provides a robust server side implementation with
>>> all the required certificate and context handling needed for this.
>>>
>>> We could tell people to use the ssl module for clients and
>>> pyOpenSSL for the server side and perhaps integrate the OpenSSL
>>> package into the ssl namespace.
>>
>> In this case, this should be decided early, so that I know if I should
>> continue caring about the ssl module or not. I'm not interested in
>> maintaining potentially obsolete code.
>
> I'll ask Jean-Paul and AB Strakt if they are up to contributing
> the pyOpenSSL code to the Python stdlib based on a contributor
> agreement. This would enable us to relicense the code undert
> the PSF license even if the original code's license is not
> changed.
>
> Once that's a done deal, we can then consider moving in the above
> direction.

I'm not sure I understand the relevance of pyopenssl here- it's pretty
clearly focused on SSL/TLS rather than on crypto. Maybe someone can
clarify?

Geremy Condra

--

___
Python tracker 

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

[issue2643] mmap_object_dealloc calls time-consuming msync(), although close doesn't

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I think Antoine misinterpreted my message. I do think that flush should 
continue to msync, except in cases where there really is no underlying file to 
sync to. It may (or may not) be unfortunate that the method is called flush, 
but nothing is gained by renaming it.

I agree that calling msync on close/dealloc is not really necessary. The 
Windows version doesn't sync, either.

--
nosy: +loewis

___
Python tracker 

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

[issue9913] Misc/SpecialBuilds.txt is out of date

[Alexander Belopolsky]

New submission from Alexander Belopolsky :

It looks like Misc/SpecialBuilds.txt has not been updated since 2.4.

This file is referenced from C-API documentation [1], but is not accessible as 
a hyperlink.

Some of the recommendations in this file are out of date, in particular those 
that recommend setting make variables where a configure switch is available.

I believe it would be best to retire Misc/SpecialBuilds.txt and move still 
relevant sections to proper .rst files.


[1] http://docs.python.org/dev/py3k/c-api/intro.html#debugging-builds

--
assignee: d...@python
components: Documentation
messages: 117076
nosy: belopolsky, d...@python
priority: normal
severity: normal
status: open
title: Misc/SpecialBuilds.txt  is out of date
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

[issue678250] test_mmap failling on AIX

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Interestingly, the matter was discussed on another issue, #2643. I
> also agree that ideally flush() should become a no-op (only in 3.2,
> since it would break compatibility). But then we should also expose a
> separate sync() method with the current behaviour.

I think you misunderstand. I'm not proposing that flush should become
a noop entirely - only for ACCESS_COPY mappings.

--

___
Python tracker 

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

[issue2643] mmap_object_dealloc calls time-consuming msync(), although close doesn't

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I notice that there's support in #678250 for making flush() a no-op.
We should still fix tp_dealloc anyway.

--

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Interestingly, the matter was discussed on another issue, #2643. I also agree 
that ideally flush() should become a no-op (only in 3.2, since it would break 
compatibility). But then we should also expose a separate sync() method with 
the current behaviour.

--
nosy: +pitrou

___
Python tracker 

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

[issue2643] mmap_object_dealloc calls time-consuming msync(), although close doesn't

[Antoine Pitrou]

Antoine Pitrou  added the comment:

It's a pity that flush() is defined like this. Ideally, if mmap claims to 
mimick ordinary file objects, flush() should be a no-op() and there should be a 
separate sync() method.

On the other hand, your (Charles-François's) patch is already much better than 
the statu quo.
If nobody objects, I think it should be committed to 3.2. Whether or not we 
should be backport it to the stable branches is a bit more delicate, since it 
/could/ break badly written applications...

On a sidenote, the mmap object has received a *lot* less attention during the 
years than the other IO primitives (especially file objects in 3.x). It should 
probably only be used for specialized cases.

--
components: +IO, Library (Lib)
stage: patch review -> commit review
title: mmap_object_dealloc does not call FlushViewOfFile on windows -> 
mmap_object_dealloc calls time-consuming msync(), although close doesn't
versions:  -Python 2.6, 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

[issue1633863] AIX: configure ignores $CC

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, committed in r84946 (3.2), r84947 (3.1) and r84948 (2.7). Thank you!

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
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

[issue678250] test_mmap failling on AIX

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Should flush be modified to do nothing in this case or should the unit test 
> be updated?

Tim is suggesting that flush should indeed become a noop. Since nobody
else speaking in favor of it being an error, I guess this is the way to
go: flush, on an ACCESS_COPY file, does nothing, and the test is fine
as it stands.

--

___
Python tracker 

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

[issue9866] Inconsistencies in tracing list comprehensions

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I have found the root cause of these differences.  The trace function is not 
called when the opcode is successfully predicted.  When computed gotos are 
enabled, opcode prediction is disabled as explained in the following comment in 
ceval.c:

Opcode prediction is disabled with threaded code, since the latter allows   

  
the CPU to record separate branch prediction information for each   

  
opcode.

Note that this issue is similar to #884022 which was resolved by disabling 
opcode prediction in dynamic profile builds.

Given that opcode prediction if off by default, I don't see much of the reason 
to try to improve tracing of predicted opcodes.

--
assignee:  -> belopolsky
resolution:  -> out of date
status: open -> pending

___
Python tracker 

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

[issue9552] ssl build under Windows always rebuilds OpenSSL

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Oops, I missed your post. Thank you, I'll commit like that.

--

___
Python tracker 

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

[issue9912] Fail when vsvarsall.bat produces stderr

[Floris Bruynooghe]

New submission from Floris Bruynooghe :

It would have saved me a lot of time if msvc9compiler would fail if executing 
the vsvarsall.bat file produced any output.  The attached patch does this and 
fails when I try to compile from within a cygwin environment.  I've also tested 
this from the normal windows command prompt and there buiding does succeed with 
this patch applied.

--
assignee: tarek
components: Distutils
files: msvc9.diff
keywords: patch
messages: 117067
nosy: eric.araujo, flub, tarek
priority: normal
severity: normal
status: open
title: Fail when vsvarsall.bat produces stderr
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18950/msvc9.diff

___
Python tracker 

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

[issue9552] ssl build under Windows always rebuilds OpenSSL

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

I want to commit py3k_openssl.patch for now, because
it is much better than before.

--

___
Python tracker 

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

[issue9552] ssl build under Windows always rebuilds OpenSSL

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto :


Added file: http://bugs.python.org/file18949/py3k_openssl_v2.patch

___
Python tracker 

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

[issue9552] ssl build under Windows always rebuilds OpenSSL

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Well, I noticed py3k_openssl.patch can suppress rebuild
> of OpenSSL nicely, but from IDE, _ssl and _hashlib
> are always rebuilt. It doesn't take so much time though.
> 
> With py3k_openssl_v2.patch, we can supress OpenSSL and
> python project rebuild nicely, but we cannot rebuild
> _ssl and _hashlib from IDE after OpenSSL sources are
> modified. We need to call "python_d build_ssl.py ..."
> manually.

I think it's better to rebuild everytime than have to invoke a console
command manually.
Also, as you say, building _ssl and hashlib is fast. The problem with
rebuilding OpenSSL is that it's very slow.

--

___
Python tracker 

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

[issue9552] ssl build under Windows always rebuilds OpenSSL

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto :


Removed file: http://bugs.python.org/file18948/py3k_openssl_v2.patch

___
Python tracker 

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

[issue9552] ssl build under Windows always rebuilds OpenSSL

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Thank you for the test.

Well, I noticed py3k_openssl.patch can suppress rebuild
of OpenSSL nicely, but from IDE, _ssl and _hashlib
are always rebuilt. It doesn't take so much time though.

With py3k_openssl_v2.patch, we can supress OpenSSL and
python project rebuild nicely, but we cannot rebuild
_ssl and _hashlib from IDE after OpenSSL sources are
modified. We need to call "python_d build_ssl.py ..."
manually.

I cannot find the best way for this issue. :-(

--
Added file: http://bugs.python.org/file18948/py3k_openssl_v2.patch

___
Python tracker 

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

[issue9864] email.utils.{parsedate, parsedate_tz} should have better return types

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

It does make sense, and email6 is like Python 3 in the sense that backward 
compatibility is not a priority.

--

___
Python tracker 

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

[issue1633863] AIX: configure ignores $CC

[Sébastien Sablé]

Sébastien Sablé  added the comment:

I am currently in the process of correcting the building of Python on AIX and 
stabilizing the tests in order to add my buildbot as a slave of the official 
buildbot master, cf post on python-dev
http://mail.python.org/pipermail/python-dev/2010-September/103774.html

Could someone please commit this (IMO straightforward) patch?

--

___
Python tracker 

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

[issue9860] Building python outside of source directory fails

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> Does this apply to 2.7 too?

I think it does, but it would be hard to sell any improvements in this area as 
a bug fix.

--

___
Python tracker 

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

[issue9864] email.utils.{parsedate, parsedate_tz} should have better return types

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> On this issue, I would much rather see email package to start using
> datetime objects to represent time rather than named or unnamed tuples.

I agree on the principle, but I don't know if it's acceptable with regards to 
compatibility. It's up to David and Barry to decide.

--

___
Python tracker 

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

[issue9621] Graphviz output for 2to3 fixer patterns

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Matt,

Can you post a sample graph in a common image format, say PNG?  I am curious to 
see it, but not curious enough to install graphviz.

--
nosy: +belopolsky

___
Python tracker 

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

[issue5505] sys.stdin.read() doesn't return after first EOF on Windows

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto :


--
Removed message: http://bugs.python.org/msg117058

___
Python tracker 

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

[issue5505] sys.stdin.read() doesn't return after first EOF on Windows

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

I guess this is not duplicate.
On HEAD of py3k, #9658 seems to be fixed,
but the issue reported here can be reproduced
even now.

--

___
Python tracker 

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

[issue9906] including elementary mathematical functions in default types

[Michael Gilbert]

Michael Gilbert  added the comment:

the  elementary functions are well-defined set, and i would include all of 
them.  that includes exp, sqrt, ln, trig, and hyperbolic functions.

i'll start a thread on python-ideas.  thanks.

--

___
Python tracker 

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

[issue9864] email.utils.{parsedate, parsedate_tz} should have better return types

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I've added #9909 as a dependency, but IMO it is less likely to be accepted than 
this feature request.

On this issue, I would much rather see email package to start using datetime 
objects to represent time rather than named or unnamed tuples.

--
dependencies: +request for calendar.dayofyear() function
nosy: +belopolsky

___
Python tracker 

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

[issue678250] test_mmap failling on AIX

[R. David Murray]

Changes by R. David Murray :


--
resolution: out of date -> 
status: closed -> open

___
Python tracker 

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

[issue9911] doc copyedits

[Georg Brandl]

Georg Brandl  added the comment:

Thanks! Committed as r84945.

--
nosy: +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

[issue678250] test_mmap failling on AIX

[Sébastien Sablé]

Sébastien Sablé  added the comment:

I would like to reopen this issue as it is still occurring in py3k on AIX 5.3 
and 6.1:

Re-running test test_mmap in verbose mode
test_access_parameter (test.test_mmap.MmapTests) ... ERROR
test_anonymous (test.test_mmap.MmapTests) ... ok
test_bad_file_desc (test.test_mmap.MmapTests) ... ok
test_basic (test.test_mmap.MmapTests) ... ok
test_context_manager (test.test_mmap.MmapTests) ... ok
test_context_manager_exception (test.test_mmap.MmapTests) ... ok
test_double_close (test.test_mmap.MmapTests) ... ok
test_entire_file (test.test_mmap.MmapTests) ... ok
test_error (test.test_mmap.MmapTests) ... ok
test_extended_getslice (test.test_mmap.MmapTests) ... ok
test_extended_set_del_slice (test.test_mmap.MmapTests) ... ok
test_find_end (test.test_mmap.MmapTests) ... ok
test_io_methods (test.test_mmap.MmapTests) ... ok
test_move (test.test_mmap.MmapTests) ... ok
test_offset (test.test_mmap.MmapTests) ... ok
test_prot_readonly (test.test_mmap.MmapTests) ... ok
test_rfind (test.test_mmap.MmapTests) ... ok
test_subclass (test.test_mmap.MmapTests) ... ok
test_tougher_find (test.test_mmap.MmapTests) ... ok

==
ERROR: test_access_parameter (test.test_mmap.MmapTests)
--
Traceback (most recent call last):
  File 
"/san_u02/home/recette/buildbot/buildbot-aix5/py3k-aix5-xlc/build/Lib/test/test_mmap.py",
 line 219, in test_access_parameter
m.flush()
mmap.error: [Errno 22] Invalid argument

--
Ran 19 tests in 0.216s

FAILED (errors=1)


Should flush be modified to do nothing in this case or should the unit test be 
updated?
thanks

--
type: crash -> 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

[issue9906] including elementary mathematical functions in default types

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

IIRC, trigonometric functions, such as sin or cos, are not considered 
"elementary" in the real domain.

The problem with this proposal is where to stop.  Right now the line is drawn 
somewhere at __abs__ and __pow__.  If you add __sin__ and __cos__, you would 
probably want to include __tan__ and the inverses to all three of sin, cos and 
tan.  What about hyperbolic functions: sinh, cosh, tanh, etc?  These are 
actually "elementary" in the usual sense.

-1 and the proper forum for such suggestions in python-ideas rather then the 
bug tracker.

--
nosy: +belopolsky

___
Python tracker 

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

[issue9911] doc copyedits

[DSM]

New submission from DSM :

Various typo fixes for the docs.  As usual, I left historical documents alone 
(except for 3.1 whatsnew: fixed the spelling of Jack Diederich's name).  Fixing 
~30 means I probably introduced ~3 problems of my own, but that should still be 
a net win..

Patch against py3k r84944.

--
assignee: d...@python
components: Documentation
files: typos.patch
keywords: patch
messages: 117052
nosy: d...@python, dsm001
priority: normal
severity: normal
status: open
title: doc copyedits
versions: Python 3.3
Added file: http://bugs.python.org/file18947/typos.patch

___
Python tracker 

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

[issue678264] test_resource fails when file size is limited

[Sébastien Sablé]

Sébastien Sablé  added the comment:

I suppose the difference comes from the fact that I have:
on AIX 5.3: 
$ ulimit -f
unlimited

on AIX 6.1:
$ ulimit -f 
1048575

I think the test should be updated to not require "ulimit -f" is unlimited.

--

___
Python tracker 

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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Vlastimil Brom]

Vlastimil Brom  added the comment:

Well, of course, the surrogates probably shouldn't be handled separately in one 
module independently of the rest of the standard library. (I actually don't 
know such narrow implementation (although it is mentioned in those unicode 
quidelines 
http://unicode.org/reports/tr18/#Supplementary_Characters )

The main surprise on my part was due to the compile error rather than empty 
match as was the case with re; 
but now I see, that it is a consequence of the newly introduced wide unicode 
notation, the matching behaviour changed consistently.

(for my part, the workarounds I found, seem to be sufficient in the cases I 
work with wide unicode; most likely I am not going to compile wide unicode 
build on windows myself in the near future :-)
 vbr

--

___
Python tracker 

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

[issue678264] test_resource fails when file size is limited

[Sébastien Sablé]

Sébastien Sablé  added the comment:

For info:
this test fails on AIX 6.1 with py3k with the following error:

test test_resource failed -- Traceback (most recent call last):
  File 
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/test/test_resource.py",
 line 28, in test_fsize_ismax
self.assertEqual(resource.RLIM_INFINITY, max)
AssertionError: 2147483647 != 1073741312

The same test works on AIX 5.3.

Is it related or should I open a new issue?

--

___
Python tracker 

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

[issue6627] threading.local() does not work with C-created threads

[Nick Coghlan]

Nick Coghlan  added the comment:

On Tue, Sep 21, 2010 at 2:39 PM, Swapnil Talekar  wrote:
> Swapnil Talekar  added the comment:
> Nick, the last statement,
> "While this is correct for most purposes, it does mean that..."
> can be simplified to,
> "It means...".
> I had to read it several times before I realized, there is no "not" after 
> "does" :)

The shorter version doesn't mean the same thing though - the ctypes
arrangement *really is* correct for most purposes. The only issue is
that threading.local won't persist, since the storage is blown away as
soon as the callback returns.

> BTW, since this particular arrangement of having a temporary thread state 
> during the callback is particularly useful for ctypes (I cannot imagine any 
> other usecase) and also it sort-of breaks things, a potential feature request 
> could be to have consistent thread state during the lifetime of a C thread. I 
> don't have much idea how to do that or whether it is even possible? Would 
> anyone like to give a thought?

There's no easy way to make the thread state persist between calls, as
ctypes needs to destroy the thread state it creates at some point to
avoid a memory leak. Since it has no way of knowing when the
underlying C thread is no longer in use, it is forced to assume that
every call is going to be the last one from that thread and kill the
thread state.

--

___
Python tracker 

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