[issue8998] add crypto routines to stdlib

[geremy condra]

geremy condra  added the comment:

On Fri, Jun 18, 2010 at 2:39 AM, Daniel Urban  wrote:
>
> Daniel Urban  added the comment:
>
>>  * When I have thought about Python crypto in the stdlib, I've considered 
>> modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, 
>> ...) etc. (Caveat: haven't thought it through.)
>
> I think there is a relevant PEP: PEP 272 -- API for Block Encryption 
> Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ )
> It describes an API somewhat similar to hashlib.

Again, I'm not entirely opposed to this, but I think it represents a
lower-level API than most developers can really be safely trusted to
handle.

Geremy Condra

--

___
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 Fri, Jun 18, 2010 at 2:19 AM, Martin v. Löwis  wrote:
>
> Martin v. Löwis  added the comment:
>
>>>   * I'd prefer if the crypto API didn't become OpenSSL specific (like the 
>>> SSL one is), which would theoretically allow switching in other crypto 
>>> provider(s).
>>
>> I agree in theory, although I'm not sure how important this is likely
>> to be in practice.
>
> I always wanted to drop OpenSSL from the Windows binaries, and use MS
> CryptoAPI instead.

My familiarity with the CryptoAPI is limited, but I think doing this
for something like evpy would be possible. I also suspect that doing
it for anything that exposed much more than evpy does would grow very
quickly in complexity where it was possible at all.

Geremy Condra

--

___
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

[Daniel Urban]

Daniel Urban  added the comment:

>  * When I have thought about Python crypto in the stdlib, I've considered 
> modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, 
> ...) etc. (Caveat: haven't thought it through.)

I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms 
v1.0 (http://www.python.org/dev/peps/pep-0272/ )
It describes an API somewhat similar to hashlib.

--

___
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

[Martin v . Löwis]

Martin v. Löwis  added the comment:

>>   * I'd prefer if the crypto API didn't become OpenSSL specific (like the 
>> SSL one is), which would theoretically allow switching in other crypto 
>> provider(s).
>
> I agree in theory, although I'm not sure how important this is likely
> to be in practice.

I always wanted to drop OpenSSL from the Windows binaries, and use MS 
CryptoAPI instead.

--

___
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 Thu, Jun 17, 2010 at 8:01 PM, Heikki Toivonen  wrote:
>
> Heikki Toivonen  added the comment:
>
> More or less random opinions on things presented before:
>
>  * I prefer having secure defaults to over documentation, because, well, 
> people don't read documentation.

Wholeheartedly agree.

>  * If not secure defaults, then pointing out in documentation the secure way 
> AND providing examples that always show the secure way of doing things.

Not as big a fan, honestly. Most domain-specific projects can count on
those reading the documentation to have a good idea of what it is that
they actually want to do; in crypto this does not seem to be the case
very often, and that's a tricky problem to fix that in the scope of a
recipe or piece of documentation.

>  * I can't comment on aes 192 vs 256 as I have not really kept up with that, 
> but it would be good to ask the opinion(s) of the real experts in this field 
> before choosing the defaults/recommending them. Of course, if you can point 
> to an article where the experts already voice their (recent) recommendations, 
> fine.

http://eprint.iacr.org/2009/317.pdf
http://eprint.iacr.org/2009/374.pdf
http://eprint.iacr.org/2009/241.pdf

Bruce Schneier's take:
http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

The only cryptosystem/padding/etc choice in evpy I'm uncomfortable
with (at the moment ;) ) is the use of ad-hoc padding rather than
OAEP, and I only do that because that's what evp does. Of course, if
you have any other concerns I'd appreciate hearing about them.

>  * When I have thought about Python crypto in the stdlib, I've considered 
> modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, 
> ...) etc. (Caveat: haven't thought it through.)

I'm not opposed to this, but I suspect that focusing on what the
algorithms are for rather than what they are reduces the cognitive
load somewhat. Perhaps a two-tier api?

>  * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL 
> one is), which would theoretically allow switching in other crypto 
> provider(s).

I agree in theory, although I'm not sure how important this is likely
to be in practice.

>  * The library should make it easy to do the most common operations with as 
> few steps as practically possible.
>  * It would be nice if the library could provide the means to tweak lower 
> level things if you needed to. Unfortunately this has a tendency to get messy 
> quick, because crypto stuff tends to have lots of options to tweak.

100% agree. If you have any ideas- or if anyone else does- on how best
to do this, I'd be very happy to discuss it.

Geremy Condra

--

___
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

[Heikki Toivonen]

Heikki Toivonen  added the comment:

More or less random opinions on things presented before:

 * I prefer having secure defaults to over documentation, because, well, people 
don't read documentation.
 * If not secure defaults, then pointing out in documentation the secure way 
AND providing examples that always show the secure way of doing things.
 * I can't comment on aes 192 vs 256 as I have not really kept up with that, 
but it would be good to ask the opinion(s) of the real experts in this field 
before choosing the defaults/recommending them. Of course, if you can point to 
an article where the experts already voice their (recent) recommendations, fine.
 * When I have thought about Python crypto in the stdlib, I've considered 
modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, 
...) etc. (Caveat: haven't thought it through.)
 * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL 
one is), which would theoretically allow switching in other crypto provider(s).
 * The library should make it easy to do the most common operations with as few 
steps as practically possible.
 * It would be nice if the library could provide the means to tweak lower level 
things if you needed to. Unfortunately this has a tendency to get messy quick, 
because crypto stuff tends to have lots of options to tweak.

--

___
Python tracker 

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

[issue6966] Ability to refer to arguments in TestCase.fail* methods

[Hari Krishna Dara]

Hari Krishna Dara  added the comment:

Oops... the dict part should have been "dict(lhs=first, rhs=second)":

def failUnlessEqual(self, first, second, msg=None):
"""Fail if the two objects are unequal as determined by the '=='
   operator. Argument msg could optionally include string format
   operators named "lhs" and "rhs" (e.g., "%(lhs)r")
"""
if not first == second:
raise self.failureException, \
  (msg or "%(lhs)r != %(rhs)r") % dict(lhs=first, rhs=second)

--

___
Python tracker 

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

[issue6966] Ability to refer to arguments in TestCase.fail* methods

[Hari Krishna Dara]

Hari Krishna Dara  added the comment:

Changing unittest.TestCase.failUnlessEqual() to something like this will be 
very useful:


def failUnlessEqual(self, first, second, msg=None):
"""Fail if the two objects are unequal as determined by the '=='
   operator. Argument msg could optionally include string format
   operators named "lhs" and "rhs" (e.g., "%(lhs)r")
"""
if not first == second:
raise self.failureException, \
  (msg or "%(lhs)r != %(rhs)r") % dict(lhs=10, rhs=20)

--

___
Python tracker 

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

[issue6966] Ability to refer to arguments in TestCase.fail* methods

[Hari Krishna Dara]

Changes by Hari Krishna Dara :


--
nosy: +haridsv

___
Python tracker 

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

[issue9022] TypeError in wsgiref.handlers when using CGIHandler

[David]

New submission from David :

The following code produces a type error, but from what I can tell it does 
comply with PEP333. This issue appeared using Python 3.1.1 and 3.1.2 on both 
Windows and Ubuntu. I have only tried the 32 bit versions. Works fine in Python 
2.6.5.12 but I guess thats irrelevant.

-
def application(environ, start_response):
start_response('200 OK',[('Content-type','text/html')])
return ['Hello World!']

from wsgiref.handlers import CGIHandler
CGIHandler().run(application)
-
Traceback (most recent call last):
  File "C:\Python31\lib\wsgiref\handlers.py", line 75, in run
self.finish_response()
  File "C:\Python31\lib\wsgiref\handlers.py", line 116, in finish_response
self.write(data)
  File "C:\Python31\lib\wsgiref\handlers.py", line 210, in write
self.send_headers()
  File "C:\Python31\lib\wsgiref\handlers.py", line 266, in send_headers
self.send_preamble()
  File "C:\Python31\lib\wsgiref\handlers.py", line 196, in send_preamble
self._write('Status: %s\r\n' % self.status)
  File "C:\Python31\lib\wsgiref\handlers.py", line 402, in _write
self.stdout.write(data)
TypeError: must be str, not bytes
-

--
components: Library (Lib)
messages: 108073
nosy: toxicdav3
priority: normal
severity: normal
status: open
title: TypeError in wsgiref.handlers when using CGIHandler
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

[issue1731717] race condition in subprocess module

[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

[issue1452] subprocess's popen.stdout.seek(0) doesn't raise an error

[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

[issue3687] Popen() object stdout attribute reassignment behaviour

[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

[issue9021] no copy.copy problem description

[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

[issue8937] SimpleHTTPServer should contain usage example

[anatoly techtonik]

anatoly techtonik  added the comment:

And I am not RDM. =)

--

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch

[anatoly techtonik]

anatoly techtonik  added the comment:

Just stumbled upon this stuff. Good job. I can already see how it can be useful.

--
nosy: +techtonik

___
Python tracker 

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

[issue6543] traceback presented in wrong encoding

[STINNER Victor]

STINNER Victor  added the comment:

I tested the last patch on Windows: it does fix the bug, the traceback is 
displayed correctly in my terminal charset (cp850).

I commited the fix to Python 3.1 (r82063) and 3.2 (r82059+r82061).

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

[issue9021] no copy.copy problem description

[anatoly techtonik]

New submission from anatoly techtonik :

`copy` module covers very important aspect of Python programming. However its 
documentation doesn't provide any intro or overview of this problem starting 
right from details. When people meet `copy` construction in the code - the 
refer to module documentation and its doesn't completely answer two basic 
questions they have:

1. why copy module is needed (i.e. what's the problem with var assignment)
2. when and where it should be used

--
assignee: d...@python
components: Documentation
messages: 108069
nosy: d...@python, techtonik
priority: normal
severity: normal
status: open
title: no copy.copy problem description
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

[issue3874] documentation bug: HTMLParser needs to document unknown_decl

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I understand that getting no response to a submission is not pleasant. I do not 
like it either. That is partly why I have started reviewing old issues. In the 
past couple of weeks, I have gotten old two orphaned patches applied by 
updating the headers, reading the patch, and adding a first-response approval 
message that got the attention of someone with code-commit privileges. I hope 
you agree that late is better than never.

I just discovered the nosy-count box on the search page. 351 open issues with a 
nosy count of 1 (which means no response unless someone responded and then 
removed themself) is too many. We need more issue reviewers.

As to your message: this is *our* tracker, not my tracker. My participation is 
as much voluntary as yours. I hope you do not really give up on improving 
Python and its documentation.

I did not expect that you *should* have known submission details. That is why I 
tried to inform you. In particular, when an issue is marked as 'documentation', 
it is automatically assigned to 'd...@python', a pseudo-user standing in for 
people who handle doc revisions. Now they will see this issue, whereas they 
would not have before.

Please excuse me for not remembering the title as I responded to the message. 
It is best if message text stands alone. Again, I hope you would agree that an 
somewhat ignorant response may be better than none.

In order for the doc maintainers to add an entry, someone knowledgeable must 
write it. Your paragraph of explanation is a start, but more editing is needed.

Looking at dir(html.parser.HTMLParser) and help(...), I see that there are 
several public internal methods. Some have doc strings that show up with 
help(), some do not. I thing all should. Some are defined on HTMLParser and 
some inherited from the undocumented (I believe) _markupbase.ParserBase.

I see that there are also several (completely undocumented except fir dir()) 
private ('_xyz') internal methods. This implies to me that the public internal 
methods were made public rather than private because there might be reason to 
override them. If so, perhaps there should be a new subsection on public 
internal methods to explain what is what with them. What do you think? Document 
just one, some, or all?

--

___
Python tracker 

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

[issue9020] 2.7: eval hangs on AIX

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

Py_CHARMASK(c) = 4294967295

And I think I found the problem: from Include/Python.h

/* Convert a possibly signed character to a nonnegative int */
/* XXX This assumes characters are 8 bits wide */
#ifdef __CHAR_UNSIGNED__
#define Py_CHARMASK(c)  (c)
#else
#define Py_CHARMASK(c)  ((unsigned char)((c) & 0xff))
#endif

__CHAR_UNSIGNED__ is defined to 1, but when I printed the value of sizeof(c) in 
the above while loop, it printed 4. Therefore .. c is 32 bits side.

--

___
Python tracker 

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

[issue9020] 2.7: eval hangs on AIX

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

I traced the "infinite loop" to tokenizer.c:tok_get around line 1368:

while (Py_ISALNUM(c) || c == '_') {
c = tok_nextc(tok);
}

Adding a `printf` statement at the beginning of the loop:

printf("tok_get: third while: c = %c (%d) ... Py_ISALNUM=%d\n", c, 
c, Py_ISALNUM(c));

Output:

tok_get: third while: c = � (-1) ... Py_ISALNUM=2
tok_get: third while: c = � (-1) ... Py_ISALNUM=2
tok_get: third while: c = � (-1) ... Py_ISALNUM=2
tok_get: third while: c = � (-1) ... Py_ISALNUM=2
tok_get: third while: c = � (-1) ... Py_ISALNUM=2
tok_get: third while: c = � (-1) ... Py_ISALNUM=2
tok_get: third while: c = � (-1) ... Py_ISALNUM=2
tok_get: third while: c = � (-1) ... Py_ISALNUM=2
[...]


I may not spend much time on this bug, unless someone can hint at what might 
have gone wrong here?

As for 2.6-maint, I will find that out sometime this week.

--

___
Python tracker 

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

[issue8203] IDLE about dialog credits raises UnicodeDecodeError

[STINNER Victor]

STINNER Victor  added the comment:

Commited in Python 3.1 (r82058) and 3.2 (r82057).

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

[issue9020] 2.7: eval hangs on AIX

[R. David Murray]

R. David Murray  added the comment:

Since it works fine on Linux, maybe you could do some bisecting on the revision 
history to try to identify what rev broke it on AIX?

How does it behave with the head of the current 2.6 maintenance branch, by the 
way?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue6543] traceback presented in wrong encoding

[STINNER Victor]

STINNER Victor  added the comment:

Update and improve the patch:
 - Update the patch to py3k (replace tabs by spaces)
 - check if _PyUnicode_AsString() result is NULL
 - _Py_FindSourceFile() returns the file instead of NULL on success!
 - use directly "utf-8" instead of calling PyUnicode_GetDefaultEncoding() for 
the default source code encoding (which is constant)
 - use PyUnicode_FromFormat() instead of PyOS_snprintf() in tb_displayline() to 
avoid conversion from unicode to utf-8 and then convert utf-8 back to unicode 
(in PyFile_WriteString). name type is now PyObject*
 - reindent also PyTracebackObject structure in traceback.h, just because I 
hate tabs :-)

--
Added file: http://bugs.python.org/file17702/traceback-encoding-2.patch

___
Python tracker 

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

[issue5115] Extend subprocess.kill to be able to kill process groups

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

A strong +1 on adding this feature.

I was wondering... what if process A runs a subprocess B which runs a 
subprocess C. Is C still considered a children of A and gets killed as well?

Does os.setpgid() takes care of such a thing? What about Windows instead?

--

___
Python tracker 

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

[issue2267] datetime.datetime operator methods are not subclass-friendly

[Mark Dickinson]

Mark Dickinson  added the comment:

I had understood that the rule was that alternate constructors should be 
classmethods, for consistency with __new__.  (Well, except that __new__ is 
actually a staticmethod, of course... )

E.g., after "class MyDecimal(Decimal): pass", MyDecimal('2.3') produces a 
MyDecimal instance, and by analogy MyDecimal.from_float(2.3) should also 
produce a MyDecimal instance.  It's exactly the same type of function as the 
class constructor.

I don't think it would do any harm to get clarification from python-dev on the 
underlying reasons.

--

___
Python tracker 

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

[issue2267] datetime.datetime operator methods are not subclass-friendly

[Brett Cannon]

Brett Cannon  added the comment:

There is a difference between methods and overridden operators (slightly) in 
terms of cognitive understanding. I mean creating a new instance from a 
timestamp seems like an operation on the object by the object. Addition, 
though, seems like a creation of a new object by the two objects working 
together, which suggests contravariance.

Best I can think of. Otherwise ask on python-dev since Guido called the 
operator overriding expectation.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Brett Cannon]

Brett Cannon  added the comment:

I would not worry about the history too much; the code has been forked and 
pulling it back in means there is already some history missing. Just do what is 
easiest.

--

___
Python tracker 

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

[issue9020] 2.7: eval hangs on AIX

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

eval('ghjsdjhgh') too hangs, btw.

--

___
Python tracker 

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

[issue9020] 2.7: eval hangs on AIX

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

I first noticed this when `test_compare_function_objects` was taking forever to 
run. The culprit is that the following statement just hangs forever. Note that 
"eval(2)", for instance, runs fine, but when a builtin object is used (eg: 
None, True), it hangs.

  python -c "eval('None')"

This is reproducible on Python 2.7 (rc1 and latest trunk) and AIX 5.1.

This is regression, as it used to work on 2.6.

--
components: Interpreter Core, Tests
messages: 108057
nosy: srid
priority: normal
severity: normal
status: open
title: 2.7: eval hangs on AIX
type: resource usage
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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am attaching datetime-sandbox-pypy.diff, a plain diff between six-year-old 
sandbox and pypy versions.  (Plain diff is cleaner than unified diff.)

You can see that the differences are trivial.  I notice, however that original 
datetime implementation was returning subclass instances from operations on 
datetime subclass instances.  Brett, this is off-topic hear, but I would 
appreciate your take on msg107410.

BTW, in order to preserve history, it may be a good idea to develop this in a 
branch off datetime sandbox and merge it back when ready.

--
Added file: http://bugs.python.org/file17701/datetime-sandbox-pypy.diff

___
Python tracker 

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

[issue1726687] Bug found in datetime for Epoch time = -1

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
priority: normal -> low
stage: patch review -> unit test needed
versions: +Python 3.1 -Python 2.7

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Brett Cannon]

Brett Cannon  added the comment:

I would simply email their developer mailing list (find it at 
http://pypy.org/contact.html) and say that you are willing to work on this. 
Maciej and I have discussed this before, so this won't be a total shock to them.

As for Raymond's comment, I think he understood what I meant. What he is 
worried about is that datetime as PyPy has implemented it is done in RPython 
which is a custom subset of Python, and not a "normal" Python implementation. 
But if they have simply been maintaining the pure Python version that Tim wrote 
way back in the day then I suspect it's not in RPython.

--

___
Python tracker 

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

[issue1726687] Bug found in datetime for Epoch time = -1

[STINNER Victor]

STINNER Victor  added the comment:

> Is this important enough to try to get in 2.7 before rc2?

I prefer to not include this patch in 2.7. I don't think that many people have 
this problem and it can be fixed later. It's too late for 2.7. Should it be 
fixed in 2.7.1 or only in 3.2 (and maybe in 3.1)?

--

___
Python tracker 

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

[issue3874] documentation bug: HTMLParser needs to document unknown_decl

[Fred L. Drake, Jr.]

Changes by Fred L. Drake, Jr. :


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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

>> One, we should not blindly pull in the PyPy code
>> without some core PyPy developer being in on this
>
> I concur.  Much of PyPy code is written for a restricted subset of
> Python instead of clean, idiomatic modern Python.

Raymond, I think you misread Brett's comment the same way as I did when I first 
saw it.  Brett wrote "core PyPy developer", not "core CPython developer".  Of 
course this will go through normal patch review process and will be looked at 
by at least two cpython developers before it goes it.  I also agree with Brett 
that it would be great to get input from PyPy developers and they may see 
benefit from 2.7 and 3.x ports of their code.  I am just not familiar with PyPy 
community and will have to research how to approach them.

--

___
Python tracker 

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

[issue3874] documentation bug: HTMLParser needs to document unknown_decl

[jeff]

jeff  added the comment:

On Wed, Jun 16, 2010 at 5:55 PM, Terry J. Reedy  wrote:
>
> Terry J. Reedy  added the comment:
>
> Documentation issues should be component: documentation rather than library. 
> When submitting one, please at least indicate the module or class concerned. 
> I have never heard of 'unknown_decl' function.

It's your bug tracker. This sort of statement that says that I should
know exactly how you want bugs reported only serves to tell people
like me not to even try. In addition, it's inaccurate in this case, as
the title of the bug is that HTMLParser, which is a module in the
standard library, needs a function documented.

HTMLParser runs over HTML and calls internal functions when certain
events occur. unknown_decl is called when an unknown declaration is
found, and by default, it throws an exception. Thus, to correctly use
HTMLParser, when subclassing it, you need to override unknown_decl if
there are any unknown declarations in your HTML (or if you think there
might be).

> Preferably, indicate the specific section you want modified, by version, 
> number and name. Best is to submit a suggested text to be inserted.  You may 
> know better than most issue reviewers what should be said. Someone else will 
> add markup and possibly edit.

It's been almost 2 years since I submitted this bug. I don't know if
it applies to Python 3, and at this point I find it difficult to care.

Thanks,

Jeff

--
status: pending -> open

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> Also, this should not be marked as high priority.  It may be a
> personal priority for you, ...

Reverting priority.  I thought once an issue is assigned, the priority becomes 
the priority that assignee places on the issue. Sorry for the confusion.

--
priority: high -> normal

___
Python tracker 

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

[issue9018] os.path.normcase(None) does not raise an error on linux and should

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I've only marked this for 3.2 because I suspect there may be linux code 
> out there that this will break,

It should be noticed that Linux-only code has absolutely no point in using 
normcase(), since it's a no-op there.

--
nosy: +pitrou

___
Python tracker 

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

[issue9018] os.path.normcase(None) does not raise an error on linux and should

[Ezio Melotti]

Changes by Ezio Melotti :


--
keywords:  -patch

___
Python tracker 

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

[issue9018] os.path.normcase(None) does not raise an error on linux and should

[Ezio Melotti]

Ezio Melotti  added the comment:

Right now posixpath returns the argument unchanged, ntpath performs a 
.replace(), and macpath a .lower(), so when non-string (or non-bytes) are 
passed to normcase the results are:
posixpath: arg returned as-is;
ntpath: AttributeError (object has no attribute 'replace');
macpath: AttributeError (object has no attribute 'lower');

In posixpath we could reject all the non-string (and non-bytes) args, raising a 
TypeError. For consistency, the other functions should raise a TypeError too, 
but I'm not sure it's worth changing it.

Attached a simple testcase that checks that normcase raises a TypeError for 
invalid values with all the three implementations.

--
keywords: +patch
stage: unit test needed -> needs patch
Added file: http://bugs.python.org/file17700/issue9018.diff

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> One, we should not blindly pull in the PyPy code 
> without some core PyPy developer being in on this

I concur.  Much of PyPy code is written for a restricted subset of Python 
instead of clean, idiomatic modern Python.

Also, this should not be marked as high priority.  It may be a personal 
priority for you, but it is by no means essential for Py3.2 or something that 
other developers should prioritize higher than other tasks like fixing bugs.

--
nosy: +rhettinger

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Brett Cannon]

Brett Cannon  added the comment:

A couple of things about all of this.

One, we should not blindly pull in the PyPy code without some core PyPy 
developer being in on this; just common courtesy and I don't think anyone 
participating in this discussion is a PyPy developer (but I could be wrong).

Two, as David pointed out, parsing overhead is pretty minor thing to be 
worrying about thanks to bytecode. The import * solution at the end of the main 
file is the agreed-upon approach (it has been discussed at some point).

Three, for testing you can also look at test_warnings (the creation of 
_warnings led to the discussion of best practices for all of this). Basically 
you use test.support.import_fresh_module to get the pure Python version and the 
C-enhanced one, write your tests with the module being tested set on the class, 
and then subclass with the proper modules as a class attribute. I understand 
your worry, Alexander, about accidentally missing a test class for a module, 
but in practice that will be rare as people will be watching for that, and you 
just do the subclass first. There is in practice no need to get too fancy, and 
you have to make sure your tests are discoverable anyway by test runners that 
simply look for classes that inherit from unittest.TestCase.

Best alternative you could do is a metaclass that searches for tests that start 
with 'test' *and* take an argument for the module to test, and then auto-create 
methods that take *no* arguments and then call the test methods directly (after 
renaming them so that test runners don't try to use them). Then you can pass in 
the modules to test as arguments to the metaclass.

--

___
Python tracker 

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

[issue4370] warning: unknown conversion type character `z' in format

[Mark Dickinson]

Mark Dickinson  added the comment:

I agree.

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

[issue1726687] Bug found in datetime for Epoch time = -1

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Is this important enough to try to get in 2.7 before rc2?  Victor?

--
components: +Extension Modules -None
type:  -> behavior
versions: +Python 3.2 -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

[issue5023] Segfault in datetime.time.strftime("%z")

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Since this does not seem to be reproducible anymore, I am going to close this 
soon.

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

[issue4370] warning: unknown conversion type character `z' in format

[Brett Cannon]

Brett Cannon  added the comment:

According to http://gcc.gnu.org/releases.html, gcc 2.95.3 is about 9 years old, 
so we don't need to care about warnings.

--

___
Python tracker 

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

[issue2775] Implement PEP 3108

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy:  -mark.dickinson

___
Python tracker 

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

[issue9019] wsgiref.headers.Header() does not update headers list it was created with.

[Marcel Hellkamp]

New submission from Marcel Hellkamp :

The current (3.x) implementation of wsgiref.headers.Headers() does not match 
the documentation.

Documented behaviour:
"Any changes made to the new Headers object will directly update the headers 
list it was created with." (/Doc/library/wsgiref.rst)

Actual behaviour:
The initial headers list is not updated.

The error was introduced with revision 68205. See 
http://svn.python.org/view/python/branches/py3k/Lib/wsgiref/headers.py?view=diff&r1=68204&r2=68205

Revision 68204::
>>> from wsgiref.headers import Headers
>>> l = []
>>> h = Headers(l)
>>> h.add_header('Test','Test')
>>> l
[('Test', 'Test')]

Revision 68205::
>>> from wsgiref.headers import Headers
>>> l = []
>>> h = Headers(l)
>>> h.add_header('Test','Test')
>>> l
[]

--
components: Library (Lib)
messages: 108042
nosy: Marcel.Hellkamp
priority: normal
severity: normal
status: open
title: wsgiref.headers.Header() does not update headers list it was created 
with.
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue6641] datetime.strptime doesn't support %z format ?

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
stage: commit 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

[issue6641] datetime.strptime doesn't support %z format ?

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Committed in r82053.

--

___
Python tracker 

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

[issue7261] Document 2.x -> 3.x round changes in "What's New" documents.

[Mark Dickinson]

Mark Dickinson  added the comment:

Applied in r82051 (py3k) and r82052 (release31-maint).

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

[issue6641] datetime.strptime doesn't support %z format ?

[Mark Dickinson]

Mark Dickinson  added the comment:

LGTM.

--

___
Python tracker 

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

[issue8469] struct - please make sizes explicit

[Mark Dickinson]

Changes by Mark Dickinson :


--
status: open -> closed

___
Python tracker 

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

[issue6641] datetime.strptime doesn't support %z format ?

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

issue6641a.diff fixes the nits that Mark found and makes the tests robust with 
respect to change of timezones.  Tested with all timezones avalilable on OSX 
including TZ="Eire".  (Ever heard of Ouagadougou?)

Parsing RFC 3339's HH:MM format is a separate issue. I am +1 on either adding 
%:z specifier or simply allow HH:MM for %z.

--
resolution:  -> accepted
Added file: http://bugs.python.org/file17699/issue6641a.diff

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[R. David Murray]

R. David Murray  added the comment:

I don't see how "moving the import to setUp" is going to avoid having to 
explicitly run each set of tests twice, though.

--

___
Python tracker 

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

[issue4452] Incorrect docstring of os.setpgrp

[Senthil Kumaran]

Senthil Kumaran  added the comment:

The docstring "Make this process the process group leader" is proper for 
setpgrp. Fixed in r82047, r82048, r82049 and r82050.

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Porting PyPy implementation to 2.7 was fairly easy.  I am posting the patch 
which makes PyPy datetime.py pass regression tests when dropped in the trunk.

I expect 3.x port to be uneventful as well.  Raising the priority because I 
would like to check this in before other datetime feature requests.

--
keywords: +patch
priority: low -> high
Added file: http://bugs.python.org/file17698/PyPy-2.7.diff

___
Python tracker 

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

[issue6641] datetime.strptime doesn't support %z format ?

[Mark Dickinson]

Mark Dickinson  added the comment:

In test_datetime:


==
ERROR: test_strptime (__main__.TestDateTime)
--
Traceback (most recent call last):
  File "Lib/test/test_datetime.py", line 1741, in test_strptime
dt = strptime("-0500 EST", "%z %Z")
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 483, in 
_strptime_datetime
tt, fraction = _strptime(data_string, format)
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 336, in 
_strptime
(data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'

==
ERROR: test_strptime (__main__.TestDateTimeTZ)
--
Traceback (most recent call last):
  File "Lib/test/test_datetime.py", line 1741, in test_strptime
dt = strptime("-0500 EST", "%z %Z")
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 483, in 
_strptime_datetime
tt, fraction = _strptime(data_string, format)
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 336, in 
_strptime
(data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'

--

___
Python tracker 

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

[issue6641] datetime.strptime doesn't support %z format ?

[Mark Dickinson]

Mark Dickinson  added the comment:

Hmm. Hold on a sec;  I'm getting test failures...

--

___
Python tracker 

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

[issue6641] datetime.strptime doesn't support %z format ?

[Mark Dickinson]

Mark Dickinson  added the comment:

Doc nit: "When ``%z`` directive" -> "When the ``%z`` directive"

The _strptime._strptime docstring is inaccurate:  it claim to return a time 
struct, but actually returns tuple, int;  please could you also add docstrings 
for _strptime_time and _strptime_datetime?

Spacing in datetimemodule.c:  "if( module == NULL)" -> "if (module == NULL)".  
Also, is there any particular reason for initializing 'result' to NULL?  (Or 
even for using result at all;  you could just do "return 
PyObject_CallMethod(... ").

I'm mildly distressed by the inability of strptime to parse UTC offsets in the 
+HH:MM form that str(timezone) produces, but I'm not sure what the solution to 
that is.

Otherwise, this all looks good to my non-expert eye.

--
assignee: mark.dickinson -> belopolsky

___
Python tracker 

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

[issue4452] Incorrect docstring of os.setpgrp

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Yes, its valid doc change request. Thought it means the same, the minor 
docstring improvement can be done.

--
nosy: +orsenthil

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> The only alternative is to manually duplicate tests, these leads to very
> poor test coverage because of the average developer's laziness (json is
> an example).

No, here is another alternative:


==> _example.py <==
def foo():
print(__name__)

==> example.py <==
def foo():
print(__name__)
try:
from _example import *
except ImportError:
pass

==> test_example.py <==
import sys
sys.modules['_example'] = None
import example
example.foo()
del sys.modules['_example']
import _example as example
example.foo()

With the code above,

$ ./python.exe test_example.py
example
_example


If we move import to setUp(), we can run each test case twice: with and without 
native code.  Tests that are specific to one implementation can be run once or 
skipped conditionally on per test method basis.

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky  added the comment:
> 
>> To avoid the wasted memory and import time, it's better to use:
>>
>> try:
>>from _cmodule import *
>> except ImportError:
>>from _pymodule import *
>>
> 
> .. also this makes it harder to prototype things in Python or have mixed 
> Python/C modules.  The goal is to use Python implementation unless native 
> implementation exists on per function/class basis.  The syntax above makes it 
> all or nothing.

Why ?

You can have the Python parts that are used by both implementation
defined in the datetime.py module.

Alternatively, you could write:

try:
# Use the faster C version
from _module import *
except ImportError:
# Use Python
class datetime:
...

I find that rather ugly, though.

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I looked at test_io and don't like that approach.  It seems to require
> subclassing each TestCase twice for C and Python.  There is no
> mechanism to assure that all tests are replicated that way.

Subclassing /is/ the mechanism :)
Furthermore, some rare tests are Py-specific and some rare others are
C-specific: you want specific test classes for them anyway.

The only alternative is to manually duplicate tests, these leads to very
poor test coverage because of the average developer's laziness (json is
an example).

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Thu, Jun 17, 2010 at 10:32 AM, Antoine Pitrou  wrote:
..
>> Is there direct regrtest support for this?
>
> You can take a look at test_io, test_memoryio or test_heapq for inspiration.
>

I looked at test_io and don't like that approach.  It seems to require 
subclassing each TestCase twice for C and Python.  There is no mechanism to 
assure that all tests are replicated that way.

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky  added the comment:
> 
> On Thu, Jun 17, 2010 at 10:31 AM, Marc-Andre Lemburg  
> wrote:
> ..
>> To avoid the wasted memory and import time, it's better to use:
>>
>> try:
>>from _cmodule import *
>> except ImportError:
>>from _pymodule import *
>>
> 
> Hmm, I cannot find the relevant thread, but I thought this was rejected at 
> some point.  Personally, I don't like this at all for the following reasons:
> 
> 1. This introduces two _.. names instead of one.
> 
> 2. This departs from established convention that C (or native) implementation 
> for modulename is in _modulename, not _cmodulename.  Non-C implementations 
> may still provide native _modulename, but would not want to call it 
> _cmodulename.
> 
> 3. Hiding python code in _pymodule makes it harder to find it.

Well, you wanted to have two implementation of the same thing in the
stdlib :-) I personally don't think that's a good idea. We've had
trouble in the past of keeping pickle.py and cPickle.c in sync, it's
not going to be much different with those two datetime implementations.

In any case, we shouldn't make regular CPython use of datetime slower
and use more memory, just to make life easier for PyPy.

>> Why not import the two modules directly ?
>>
>> import _cmodule as module
>> and
>> import _pymodule as module
>>
> 
> Because this requires having two modules in the first place.

Where's the problem ? Disk space ?

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[R. David Murray]

R. David Murray  added the comment:

I think we have no standard for this yet, though it has been discussed.  If you 
can't find a python-dev thread about it, you should probably start a new one.

As one example, heapq does:

  try:
  from _heapq import *
  except ImportError:
   pass

after having defined the python.  Which does not incur parsing overhead in most 
real-world situations since most distributions generate the .pyc files during 
install, but does incur the execution overhead on first import.

On the other hand, io doesn't fall back to _pyio at all (perhaps this is a bug).

As for the tests, the way this is typically done is that you define a base test 
class that is *not* a TestCase, and then you define two subclasses that are 
TestCases and mix in the base class.  You then assign the appropriate module 
(or function or whatever) under test as attributes of the subclasses, and the 
base class uses those attributes to run the tests.  That way you know all the 
tests are run for both the Python and the C implementation.

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> To avoid the wasted memory and import time, it's better to use:
>
> try:
>from _cmodule import *
> except ImportError:
>from _pymodule import *
>

.. also this makes it harder to prototype things in Python or have mixed 
Python/C modules.  The goal is to use Python implementation unless native 
implementation exists on per function/class basis.  The syntax above makes it 
all or nothing.

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Thu, Jun 17, 2010 at 10:31 AM, Marc-Andre Lemburg  
wrote:
..
> To avoid the wasted memory and import time, it's better to use:
>
> try:
>    from _cmodule import *
> except ImportError:
>    from _pymodule import *
>

Hmm, I cannot find the relevant thread, but I thought this was rejected at some 
point.  Personally, I don't like this at all for the following reasons:

1. This introduces two _.. names instead of one.

2. This departs from established convention that C (or native) implementation 
for modulename is in _modulename, not _cmodulename.  Non-C implementations may 
still provide native _modulename, but would not want to call it _cmodulename.

3. Hiding python code in _pymodule makes it harder to find it.

..
> Why not import the two modules directly ?
>
> import _cmodule as module
> and
> import _pymodule as module
>

Because this requires having two modules in the first place.

--

___
Python tracker 

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

[issue8857] socket.getaddrinfo needs tests

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


Removed file: http://bugs.python.org/file17693/getaddrinfotest.patch

___
Python tracker 

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

[issue8857] socket.getaddrinfo needs tests

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


Removed file: http://bugs.python.org/file17692/getaddrinfotest.patch

___
Python tracker 

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

[issue8857] socket.getaddrinfo needs tests

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

> Anyway, getaddrinfo() on FreeBSD/Qemu gives this

It seems SOCK_DGRAM is always returned which, as far as I know, doesn't make 
sense with FTP and SSH protocols. 
At this point, assuming getaddrinfo() correctly binds the original C function, 
I'd be for just removing this test since it's unreliable across all platforms.
New patch is in attachment.

--
Added file: http://bugs.python.org/file17697/getaddrinfo.patch

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Is this still the state of the art?  What about parsing overhead?

The io module has three modules:
- io.py just imports everything from _io
- _io is the default C implementation
- _pyio.py must be imported explicitly to get the pure Python implementation

=> no parsing overhead for the default case of importing the C implementation

> Is there direct regrtest support for this?

You can take a look at test_io, test_memoryio or test_heapq for inspiration.

--
nosy: +pitrou

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky  added the comment:
> 
> I would like to move this forward.  The PyPy implementation at
> 
> http://codespeak.net/pypy/dist/pypy/lib/datetime.py
> 
> claims to be based on the original CPython datetime implementation from the 
> time when datetime was a python module.  I looked through the code and it 
> seems to be very similar to datetime.c.  Some docstings and comments are 
> literal copies.  I think it will not be hard to port that to 3.x.
> 
> I have a few questions, though.
> 
> 1. I remember seeing python-dev discussion that concluded that the best way 
> to distribute parallel C and Python implementations was to have module.py 
> with the following:
> 
> # pure python implementation
> 
> def foo():
> pass
> 
> def bar():
> pass
> 
> # ..
> 
> try:
> from _module import *
> except ImportError:
> pass
> 
> Is this still the state of the art?  What about parsing overhead?

That approached was used for modules where the C bits replaced the Python
ones. The Python bites were then typically removed altogether.

To avoid the wasted memory and import time, it's better to use:

try:
from _cmodule import *
except ImportError:
from _pymodule import *

> 2. Is there a standard mechanism to ensure that unitests run both python and 
> C code?  I believe sys.module['_module'] = None will prevent importing 
> _module.  Is there direct regrtest support for this?

Why not import the two modules directly ?

import _cmodule as module
and
import _pymodule as module

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I would like to move this forward.  The PyPy implementation at

http://codespeak.net/pypy/dist/pypy/lib/datetime.py

claims to be based on the original CPython datetime implementation from the 
time when datetime was a python module.  I looked through the code and it seems 
to be very similar to datetime.c.  Some docstings and comments are literal 
copies.  I think it will not be hard to port that to 3.x.

I have a few questions, though.

1. I remember seeing python-dev discussion that concluded that the best way to 
distribute parallel C and Python implementations was to have module.py with the 
following:

# pure python implementation

def foo():
pass

def bar():
pass

# ..

try:
from _module import *
except ImportError:
pass

Is this still the state of the art?  What about parsing overhead?

2. Is there a standard mechanism to ensure that unitests run both python and C 
code?  I believe sys.module['_module'] = None will prevent importing _module.  
Is there direct regrtest support for this?

--

___
Python tracker 

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

[issue850997] mbcs encoding ignores errors

[Tim Golden]

Tim Golden  added the comment:

I'm unlikely to get to it soon. If there's no urgency I can
look at it later. FWIW, it's not something I'm especially
familiar with.

On 12/06/2010 01:02, STINNER Victor wrote:
>
> STINNER Victor  added the comment:
>
> Tim: are you interested in testing this patch?
>
> --
> nosy: +tim.golden
>
> ___
> Python tracker
> 
> ___

--

___
Python tracker 

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

[issue9018] os.path.normcase(None) does not raise an error on linux and should

[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

[issue7370] BaseHTTPServer reinventing rfc822 date formatting

[R. David Murray]

R. David Murray  added the comment:

The HTTP RFCs reference the email RFCs for the date format, so the email 
package is the logical place for this function: email is the correct 
responsible party.  In any case, the function resides in email.utils, which has 
no dependencies on anything else in the email package.  Of course, it does have 
dependencies on other parts of the python standard library, but I hardly think 
you'd want every module re-implementing every stdlib function.

--

___
Python tracker 

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

[issue9017] doctest option flag to enable/disable some chunk of doctests?

[Brian Curtin]

Changes by Brian Curtin :


--
components: +Library (Lib) -Tests
stage:  -> unit test needed
title: What do you think about an Option Flags to enable/disable some chunk of 
doctest file ? -> doctest option flag to enable/disable some chunk of doctests?
type:  -> feature request
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

[issue9018] os.path.normcase(None) does not raise an error on linux and should

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue9018] os.path.normcase(None) does not raise an error on linux and should

[R. David Murray]

New submission from R. David Murray :

os.path.normcase(None) raises an error on Windows but returns None on linux.  
os.path.abspath(None) raises an error in both cases.  os.path.normcase(None) 
should raise an error on linux.

I've only marked this for 3.2 because I suspect there may be linux code out 
there that this will break, so the fix should probably only be applied to 3.2.  
(I discovered this because a unit test someone else wrote passed on linux but 
failed on windows.)

--
keywords: easy
messages: 108016
nosy: r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: os.path.normcase(None) does not raise an error on linux and should
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

[issue8937] SimpleHTTPServer should contain usage example

[anatoly techtonik]

anatoly techtonik  added the comment:

The example is really helpful. I was surprised to learn that SimpleHTTPServer 
can be called from command line with port argument. I thought it is only for 
testing. Another missed aspect is that it is possible to use 
SimpleHTTPRequestHandler with TCPServer, so HTTPServer is not required. But now 
I wonder about compatibility of handlers vs servers.

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Mark Dickinson  added the comment:

That sounds like a reasonable quick fix.

Here's a patch.

--
keywords: +patch
stage:  -> commit review
Added file: http://bugs.python.org/file17696/issue9011.patch

___
Python tracker 

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

[issue9008] CGIHTTPServer support for arbitrary CGI scripts

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le jeudi 17 juin 2010 à 13:22 +, anatoly techtonik a écrit :
> 
> > That's a lot of things which others do not perceive as important or even
> > desireable. Chances are you are going to have to implement them yourself
> > if you really want them. In any case, just complaining won't change
> > anything.
> 
> I am just trying to answer why I can't contribute patches myself.

Thank you, I think you have made your point.
Now I suggest you propose patches to improve the workflow on the
relevant mailing-list(s) or issue tracker.

--

___
Python tracker 

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

[issue9008] CGIHTTPServer support for arbitrary CGI scripts

[anatoly techtonik]

anatoly techtonik  added the comment:

> That's a lot of things which others do not perceive as important or even
> desireable. Chances are you are going to have to implement them yourself
> if you really want them. In any case, just complaining won't change
> anything.

I am just trying to answer why I can't contribute patches myself. Hope
the idea to put workflow first after getting enough experience over
past year was clear. I work on this workflow alone. If smb. would also
feel that is it a more important problem than immediate patch - I'd be
glad to collaborate.

>> Ok. Let me try to express it in English once more:
>> search: To be a maintainer I need:
>> replace: To be willing to become a maintainer I need:
>
> Nobody proposed you to become a maintainer, so this is still besides the
> point. First contribute significantly, and then we'll see.

Can you estimate my contributions so far?
I suspect I should stop wasting time if there are aren't any.

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Alex Samuel]

Alex Samuel  added the comment:

How about saving the original value of STR(pnum) and restoring it after 
calling ast_for_atom()?

This is not thread-safe, but I don't understand Python's threading model 
well enough to know whether the GIL is held in this function.

On 6/17/2010 8:40 AM, Mark Dickinson wrote:
>
> Mark Dickinson  added the comment:
>
> Fixed in r82043 (py3k) and r82044 (release31-maint), simply by removing the 
> relevant 'if' block.
>
> For 2.x, Antoine (on IRC) pointed out that there might well be third party 
> code that depends on -0x8000 being an int rather than a long (32-bit 
> machine), so changing that behaviour could cause breakage.
>
> Can anyone propose a fix that doesn't change behaviour?
>
> --
>
> ___
> Python tracker
> 
> ___

--

___
Python tracker 

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

[issue9010] Infinite loop in imaplib.IMAP4_SSL when used with Gmail

[R. David Murray]

R. David Murray  added the comment:

OK, this is out of date, then.  Nosy people, sorry for the noise.

--
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

___
Python tracker 

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

[issue9008] CGIHTTPServer support for arbitrary CGI scripts

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> pbranch is the next in my list, still do not have time to dig all these tools.
> For now I have these unsolved workflow problems:
> [...]

That's a lot of things which others do not perceive as important or even
desireable. Chances are you are going to have to implement them yourself
if you really want them. In any case, just complaining won't change
anything.

> Ok. Let me try to express it in English once more:
> search: To be a maintainer I need:
> replace: To be willing to become a maintainer I need:

Nobody proposed you to become a maintainer, so this is still besides the
point. First contribute significantly, and then we'll see.

--

___
Python tracker 

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

[issue9017] What do you think about an Option Flags to enable/disable some chunk of doctest file ?

[harobed]

New submission from harobed :

Hi,

in some doctest, I need to stop doctest from a position because the following 
test is a draft, not implemented.

I dream something like this :

   >>> test_a()
   True

   >>> test_b()
   False

   #doctest: +DISABLE

   >>> test_c()
   True

   >>> test_d()
   False

   #doctest: +ENABLE

   >>> test_e()
   True

   >>> test_f()
   False

Here, test_c and test_d aren't executed.

What do you think about this idea ? If it is a good idea, I can implement it.

Thanks for your comments,
Stephane

--
components: Tests
messages: 108008
nosy: harobed
priority: normal
severity: normal
status: open
title: What do you think about an Option Flags to enable/disable some chunk of 
doctest file ?

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Changes by Mark Dickinson :


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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Mark Dickinson  added the comment:

Fixed in r82043 (py3k) and r82044 (release31-maint), simply by removing the 
relevant 'if' block.

For 2.x, Antoine (on IRC) pointed out that there might well be third party code 
that depends on -0x8000 being an int rather than a long (32-bit machine), 
so changing that behaviour could cause breakage.

Can anyone propose a fix that doesn't change behaviour?

--

___
Python tracker 

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

[issue9008] CGIHTTPServer support for arbitrary CGI scripts

[anatoly techtonik]

anatoly techtonik  added the comment:

>> Conflict resolution takes a lot of time
>> and I can't afford maintaining a separate copy of Python checkout for
>> every patch
>
> Then try various hg features such as named branches, or bookmarks, or mq, or 
> pbranch, etc.
> (or any SVN-facing tool you would like, including git-svn, bzr-svn, etc.)

pbranch is the next in my list, still do not have time to dig all these tools.
For now I have these unsolved workflow problems:
1. patches are not tied to specific bug ticket (can only be manually uploaded)
2. I would like to receive feedback on patches inline (like in Mercurial list)
3. I would like to see all the code related to patch (source, tests,
docs) in one place
4. Edit, preview and update docs patches online
5. Download patched source and test in one step, execute in the other

>> To be a maintainer I need:
> [snip]
>
> Most people in most open source projects seem perfectly content without such 
> an artillery of sophisticated tools/gadgets.

You account only people who found they way to be able to contribute.
Most people didn't. If you can calculate an average indicator of
active Python contributors, I will say that it can be improved by 50%
only by means of well aligned toolset.

> While the workflow can always be improved, it is not obvious to me that your 
> requirements are in any way reasonable, or even serious ("serious" as in 
> "this is the only reasonable way one can work efficiently on Python" -- 
> plenty of people, almost all of them unpaid volunteers, seem to disagree).

I never said "this is the only reasonable way one can work efficiently
on Python". I said that "there is no  reasonable way one can work
efficiently on Python and I am trying to find one". Feel the
difference.

> By the way, the first thing needed to qualify as a maintainer would be to 
> *prove* that you are up to the task. Not to have a bunch of nifty tools. In 
> other words, you can't just come and say "hey, I'd like to be a maintainer" 
> and expect this request to be granted automatically.

Ok. Let me try to express it in English once more:
search: To be a maintainer I need:
replace: To be willing to become a maintainer I need:

--

___
Python tracker 

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

[issue6884] Impossible to include file in sdist that starts with 'build' on Win32

[Adam Groszer]

Adam Groszer  added the comment:

This seems to be a major flaw, noone caring about it?

--
components: +Distutils
nosy: +Adam.Groszer
versions: +Python 2.5

___
Python tracker 

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

[issue8937] SimpleHTTPServer should contain usage example

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Yes, I felt the same way and that is the reason for providing extra
example snippets in the same Documentation. I hope you checked that
one.

--

___
Python tracker 

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

[issue8937] SimpleHTTPServer should contain usage example

[anatoly techtonik]

anatoly techtonik  added the comment:

Thank you. The wording can surely be improved, but it is much better than 
nothing. 

I'd reword the first para further:

> The :func:`test` function in the :mod:`SimpleHTTPServer` module is an example 
> of using :class:`SimpleHTTPRequestHandler` with :class:`BaseHTTPServer` class.

BTW, it is still bad, because:
1. I'd assume that test function is described in documentation and not located 
in module source
2. users usually don't know where to look for the module source - doc should be 
self-sufficient
3. SimpleHTTPServer.test() is a proxy call for BaseHTTPServer.test()

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Mark Dickinson  added the comment:

Results from Jython:

newton:jython2.5.1 dickinsm$ ./jython
Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54) 
[Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_20
Type "help", "copyright", "credits" or "license" for more information.
>>> -2147483648
-2147483648L

On the other hand, IronPython appears to detect this special case and produces 
an int instead of a long.

--

___
Python tracker 

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

[issue9011] ast_for_factor unary minus optimization changes AST

[Mark Dickinson]

Mark Dickinson  added the comment:

N.B.  That if block isn't pure optimization:  removing it gives a minor change 
in behaviour:

Currently (Python 2.7, on a 64-bit machine):

>>> -9223372036854775808
-9223372036854775808

And with the optimization removed:

>>> -9223372036854775808
-9223372036854775808L

I actually consider the second behaviour more correct than the first, since it 
follows clearly from the language rules (numeric literals have no sign, so the 
above *should* be interpreted as the unary minus operator applied to a literal, 
and that literal really is a PyLong).  But obviously the contributors to issue 
1441486 either disagree, or didn't want to introduce a regression from 2.4.

I still consider that removing that if block is the right thing to do for 2.7.  
The change in behaviour really shouldn't affect any reasonable code---anywhere 
that an int is acceptable, a long should be too.



Neil, any comments?

--
nosy: +nascheme
priority: normal -> high

___
Python tracker 

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

[issue1675951] [gzip] Performance for small reads and fix seek problem

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patch could only be applied to 3.2 (2.7 is frozen now). But the gzip code 
has changed quite a bit and I would advocate creating a new patch if you are 
interested.
Do notice that performance should also be much better in 3.2, and it is 
possible to wrap a gzip object in a io.BufferedReader object so as to reach 
even better performance.

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