[Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Sandro Tosi 
Hi all,
before opening an issue to track the request, I'd like to ask advice
here about this: extend os.chown() to accept even user/group names
instead of just uid and gid.

On a Unix system, you can call chown command passing either id or
names, so it seems (to me at least) natural to expect os.chown() to
behave similarly; but that's not the case.

I can see os module wants to be a thin wrapper around OS syscalls and
chown(2) accepts only uid/gid as input, so what would be best: extend
os.chown() or provide a chown() function in shutil module for this
purpose?

Thanks in advance,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] Daily reference leaks (234021dcad93): sum=61

2011-05-25 Thread Victor Stinner 
Le mercredi 25 mai 2011 à 15:13 +1000, Nick Coghlan a écrit :
> On Wed, May 25, 2011 at 1:09 PM,   wrote:
> > results for 234021dcad93 on branch "default"
> > 
> >
> > test_packaging leaked [128, 128, 128] references, sum=384
> 
> Is there a new cache in packaging that regrtest needs to know about
> and either ignore or clear when checking reference counts?

See the issue http://bugs.python.org/issue12167 : Antoine listed tests
leaking references, and I already fixed some of them.

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl

2011-05-25 Thread Victor Stinner 
Le mercredi 25 mai 2011 à 15:09 +1000, Nick Coghlan a écrit :
> The RAND_bytes() documentation should probably make it clearer that
> unlike the random module and RAND_pseudo_bytes(), RAND_bytes() can
> *fail* (by raising SSLError) if it isn't in a position to provide the
> requested random data.

According to the doc, both functions can fail, but it is more likely
than RAND_bytes() fail. I disabled temporary Linux random devices to
test RAND_bytes() error code:

   mv /dev/random /dev/random.xxx
   mv /dev/urandom /dev/urandom.xxx

In this case, RAND_pseudo_bytes() generates non-cryptographic random
numbers: it returns (random_bytes, False). I don't know how to test
RAND_pseudo_bytes() error code.

--

I patched test_ssl to test that RAND_bytes() raises an SSLError if there
is not enough entropy, and I also improved the documentation to detail
the error cases.

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader

2011-05-25 Thread M.-A. Lemburg 
Walter Dörwald wrote:
> On 24.05.11 12:58, Victor Stinner wrote:
>> Le mardi 24 mai 2011 à 12:42 +0200, Łukasz Langa a écrit :
>>> Wiadomość napisana przez Walter Dörwald w dniu 2011-05-24, o godz. 12:16:
>>>
> I don't see which usecase is not covered by TextIOWrapper. But I know
> some cases which are not supported by StreamReader/StreamWriter.

 This could be be partially fixed by implementing generic
 StreamReader/StreamWriter classes that reuse the incremental codecs, but
 I don't think thats worth it.
>>>
>>> Why not?
>>
>> We have already an implementation of this idea, it is called
>> io.TextIOWrapper.
> 
> Exactly.
> 
> From another post by Victor:
> 
>> As I wrote, codecs.open() is useful in Python 2. But I don't know any
>> program or library using directly StreamReader or StreamWriter.
> 
> So: implementing this is a lot of work, duplicates existing
> functionality and is mostly unused.

You are missing the point: we have StreamReader and StreamWriter APIs
on codecs to allow each codecs to implement more efficient ways of
encoding and decoding streams.

Examples of such optimizations are reading the stream in
chunks that can be decoded in one piece, or writing to the stream
in a way that doesn't generate encoding state problems on the
receiving end by ending transmission half-way through a
shift block.

Of course, you won't find many direct uses of these APIs, since
most of the time, applications will simply use codecs.open() to
automatically benefit from these optimizations.

OTOH, TextIOWrapper doesn't know anything about specific encodings
and thus does not allow for such optimizations to be implemented
by codecs.

We don't have many such specialized implementations in the stdlib,
but this doesn't mean that there's no use for them. It
just means that developers and users are simply unaware of the
possibilities opened by these stateful stream APIs.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 25 2011)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2011-05-23: Released eGenix mx Base 3.2.0  http://python.egenix.com/
2011-05-25: Released mxODBC 3.1.1  http://python.egenix.com/
2011-06-20: EuroPython 2011, Florence, Italy   26 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl

2011-05-25 Thread Victor Stinner 
Le mercredi 25 mai 2011 à 08:59 +0300, Petri Lehtinen a écrit :
> So it seems to me that RAND_bytes() either returns cryptographically
> strong data or fails (is it possible to detect the failure with the
> Python function? Should this be documented?).

RAND_bytes() raises an SSLError on error. You can check if there is
enough entropy before calling RAND_bytes() using RAND_status(). I
documented this two infos.

> RAND_pseudo_bytes() always succeeds...

No, it can fail if the RAND method was changed and the current RAND
method doesn't support this operation.

Example:

>>> import ctypes
>>> from ctypes import c_void_p
>>> libssl=ctypes.cdll.LoadLibrary('libssl.so')
>>> RAND_set_rand_method=libssl.RAND_set_rand_method
>>> class rand_meth_st(ctypes.Structure): _fields_ = (('seed',
c_void_p), ('bytes', c_void_p), ('cleanup', c_void_p), ('add',
c_void_p), ('pseudorand', c_void_p), ('status', c_void_p))
... 
>>> not_supported = rand_meth_st()
>>> RAND_set_rand_method(ctypes.byref(not_supported))
>>> import ssl
>>> ssl.RAND_bytes(1)
...
ssl.SSLError: [Errno 0] None
>>> ssl.RAND_pseudo_bytes(1)
...
ssl.SSLError: [Errno 0] None
--

Cool, ssl.RAND_pseudo_bytes() raises also an error, as expected :-)

> ... but does not necessarily generate cryptographically
> strong data.

Yes, if the PRNG was not seed with enough data, the RAND_pseudo_bytes()
Python function returns (random_bytes, False).

> > >We may also add a link from random to SSL.RAND_bytes() and
> > >SSL.RAND_pseudo_bytes().
> 
> Obviously, the user needs to be familiar with the concept of
> "cryptographically strong randomness" to use these functions.

I already patched the doc of the random module to add a security
warning. Well, you don't really need to know how a CSPRNG is
implemented, just that random cannot be used for security and that
ssl.RAND_bytes() raises an error if was seeded with enough data.

Tell me if my warning is not clear:

.. warning::

   The generators of the :mod:`random` module should not be used for
   security purposes, they are not cryptographic. Use ssl.RAND_bytes()
   if you require a cryptographically secure pseudorandom number
   generator.

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl

2011-05-25 Thread Petri Lehtinen 
Victor Stinner wrote:
> I already patched the doc of the random module to add a security
> warning. Well, you don't really need to know how a CSPRNG is
> implemented, just that random cannot be used for security and that
> ssl.RAND_bytes() raises an error if was seeded with enough data.
> 
> Tell me if my warning is not clear:
> 
> .. warning::
> 
>The generators of the :mod:`random` module should not be used for
>security purposes, they are not cryptographic. Use ssl.RAND_bytes()
>if you require a cryptographically secure pseudorandom number
>generator.

Looks good to me. Regarding style, you should probably make a link,
like :func:`ssl.RAND_bytes()`.

Petri
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl

2011-05-25 Thread Eric Smith 
> Victor Stinner wrote:
>> I already patched the doc of the random module to add a security
>> warning. Well, you don't really need to know how a CSPRNG is
>> implemented, just that random cannot be used for security and that
>> ssl.RAND_bytes() raises an error if was seeded with enough data.
>>
>> Tell me if my warning is not clear:
>>
>> .. warning::
>>
>>The generators of the :mod:`random` module should not be used for
>>security purposes, they are not cryptographic. Use ssl.RAND_bytes()
>>if you require a cryptographically secure pseudorandom number
>>generator.
>
> Looks good to me. Regarding style, you should probably make a link,
> like :func:`ssl.RAND_bytes()`.

Does "are not cryptographic" have any meaning? (I'm not an expert, just
not sure). Should it not be "cryptographically secure", to match the next
sentence?

Eric.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl

2011-05-25 Thread Petri Lehtinen 
Eric Smith wrote:
> > Victor Stinner wrote:
> >> I already patched the doc of the random module to add a security
> >> warning. Well, you don't really need to know how a CSPRNG is
> >> implemented, just that random cannot be used for security and that
> >> ssl.RAND_bytes() raises an error if was seeded with enough data.
> >>
> >> Tell me if my warning is not clear:
> >>
> >> .. warning::
> >>
> >>The generators of the :mod:`random` module should not be used for
> >>security purposes, they are not cryptographic. Use ssl.RAND_bytes()
> >>if you require a cryptographically secure pseudorandom number
> >>generator.
> >
> > Looks good to me. Regarding style, you should probably make a link,
> > like :func:`ssl.RAND_bytes()`.
> 
> Does "are not cryptographic" have any meaning? (I'm not an expert, just
> not sure). Should it not be "cryptographically secure", to match the next
> sentence?

Or just remove ", they are not cryptographic" altogether?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader

2011-05-25 Thread Victor Stinner 
Le mercredi 25 mai 2011 à 11:38 +0200, M.-A. Lemburg a écrit :
> You are missing the point: we have StreamReader and StreamWriter APIs
> on codecs to allow each codecs to implement more efficient ways of
> encoding and decoding streams.
> 
> Examples of such optimizations are reading the stream in
> chunks that can be decoded in one piece, or writing to the stream
> in a way that doesn't generate encoding state problems on the
> receiving end by ending transmission half-way through a
> shift block.
> 
> ...
> 
> We don't have many such specialized implementations in the stdlib,
> but this doesn't mean that there's no use for them. It
> just means that developers and users are simply unaware of the
> possibilities opened by these stateful stream APIs.

Does at least one codec implement such implementation in its
StreamReader or StreamWriter class? And can't we implement such
optimization in incremental encoders and decoders (or in TextIOWrapper)?

I checked all multibyte codecs (UTF and CJK codecs) and I don't see any
of such optimization. UTF codecs handle the BOM, but don't have anything
looking like an optimization. CJK codecs use multibytecodec,
MultibyteStreamReader and MultibyteStreamWriter, which don't look to be
optimized. But I missed maybe something?

TextIOWrapper has an advanced buffer algorithm to prefetch (readahead)
some bytes at each read to speed up small read. It is difficult to
implement such algorithm, but it's done and it works.

--

Ok, let's stop to speak about theorical optimizations, and let's do a
benchmark to compare codecs and the io modules on reading files!

I tested Python 3.3 (70370:178d367c9733) compiled in release mode (gcc
-O3) on a Pentium4 @ 3 GHz with 2 GB of memory. I tunned manually the
number of loops to ensure that the faster test takes at least one
second. I only ran my benchmark once. See the attached bench.py file.


(1) Decode Objects/unicodeobject.c (317336 characters) from utf-8

test_io.readline(): 89.6 ms
test_codecs.readline(): 1272.8 ms
-> codecs 1320% slower than io

test_io.read(1): 1728.9 ms
test_codecs.read(1): 36395.0 ms
-> codecs 2005% slower than io

test_io.read(100): 460.7 ms
test_codecs.read(100): 3897.0 ms
-> codecs 746% slower than io

test_io.read(-1): 1911.7 ms
test_codecs.read(-1): 1740.7 ms
-> codecs 10% FASTER than io


(2) Decode README (6613 characters) from ascii

test_io.readline(): 109.9 ms
test_codecs.readline(): 1023.8 ms
-> codecs 832% slower than io

test_io.read(1): 1560.4 ms
test_codecs.read(1): 29402.6 ms
-> codecs 1784% slower than io

test_io.read(100): 866.9 ms
test_codecs.read(100): 3699.5 ms
-> codecs 327% slower than io

test_io.read(-1): 5140.2 ms
test_codecs.read(-1): 4817.9 ms
-> codecs 7% FASTER than io


(3) Decode Lib/test/cjkencodings/gb18030.txt (501 characters) from
gb18030

test_io.readline(): 1193.7 ms
test_codecs.readline(): 1474.3 ms
-> codecs 24% slower than io

test_io.read(1): 3847.7 ms
test_codecs.read(1): 27103.9 ms
-> codecs 604% slower than io

test_io.read(100): 12839.5 ms
test_codecs.read(100): 13444.2 ms
-> codecs 5% slower than io

test_io.read(-1): 2183.3 ms
test_codecs.read(-1): 1906.1 ms
-> codecs 15% FASTER than io


The readahead code does really help read(1): io is between 6 and 20
times faster than the codecs. But it does really use a more common
usecase, readline: io is between 1.2 and 13 times faster than the
codecs.

codecs is always faster (between 1.07 and 1.15 times faster than io) to
read the whole content of file using read(-1). Something should maybe be
optimized in TextIOWrapper.read() ;-) But the gain is minor if you
compare it to the gain on read(1) and readline()!

Please check my bench.py script and redo the benchmark on your own
computer!

Victor
import codecs
import sys
import time

FILENAME = "Objects/unicodeobject.c"; FILESIZE = 317336; ENCODING = 'utf-8'; LOOPS=10
FILENAME = "Lib/test/cjkencodings/gb18030.txt"; FILESIZE = 501; ENCODING = 'gb18030'; LOOPS=200

FILENAME = "README"; FILESIZE = 6613; ENCODING = 'ascii'; LOOPS=400

def bench(loops, func, *args):
t0=time.time()
for loop in range(loops):
func(*args)
dt = time.time() - t0
text = "%s.%s" % (func.__name__, test_func)
if chunk_size is not None:
text += "(%s)" % chunk_size
else:
text += "()"
print("%s: %.1f ms" % (text, dt * 1000))
return dt

def test_file(f, test_func, chunk_size):
size = 0
func = getattr(f, test_func)
while True:
if chunk_size is not None:
c = func(chunk_size)
else:
c = func()
if not c:
break
size += len(c)
assert size == FILESIZE, "%s != %s" % (size, FILESIZE)

def test_io(test_func, chunk_size):
with open(FILENAME, encoding=ENCODING) as f:
test_file(f, test_func, chunk_size)

def test_codecs(test_func, chunk_size):
with codecs.open(FILENAME, 'r', encoding=ENCODING) as f:
test_file(f, test_func, chunk_size)

print("Python %s" % sys.versi

Re: [Python-Dev] [Python-checkins] Daily reference leaks (234021dcad93): sum=61

2011-05-25 Thread Nick Coghlan 
On Wed, May 25, 2011 at 7:10 PM, Victor Stinner
 wrote:
> Le mercredi 25 mai 2011 à 15:13 +1000, Nick Coghlan a écrit :
>> On Wed, May 25, 2011 at 1:09 PM,   wrote:
>> > results for 234021dcad93 on branch "default"
>> > 
>> >
>> > test_packaging leaked [128, 128, 128] references, sum=384
>>
>> Is there a new cache in packaging that regrtest needs to know about
>> and either ignore or clear when checking reference counts?
>
> See the issue http://bugs.python.org/issue12167 : Antoine listed tests
> leaking references, and I already fixed some of them.

Thanks for the issue link. I'd seen a few of these reports go by, so
it's good to know that dealing with it is in progress.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl

2011-05-25 Thread Eric Smith 
On 05/25/2011 06:58 AM, Petri Lehtinen wrote:
> Eric Smith wrote:
>>> Victor Stinner wrote:
 I already patched the doc of the random module to add a security
 warning. Well, you don't really need to know how a CSPRNG is
 implemented, just that random cannot be used for security and that
 ssl.RAND_bytes() raises an error if was seeded with enough data.

 Tell me if my warning is not clear:

 .. warning::

The generators of the :mod:`random` module should not be used for
security purposes, they are not cryptographic. Use ssl.RAND_bytes()
if you require a cryptographically secure pseudorandom number
generator.
>>>
>>> Looks good to me. Regarding style, you should probably make a link,
>>> like :func:`ssl.RAND_bytes()`.
>>
>> Does "are not cryptographic" have any meaning? (I'm not an expert, just
>> not sure). Should it not be "cryptographically secure", to match the next
>> sentence?
> 
> Or just remove ", they are not cryptographic" altogether?

Good call. That's a better change.

Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Barry Warsaw 
On May 25, 2011, at 10:24 AM, Sandro Tosi wrote:

>before opening an issue to track the request, I'd like to ask advice
>here about this: extend os.chown() to accept even user/group names
>instead of just uid and gid.
>
>On a Unix system, you can call chown command passing either id or
>names, so it seems (to me at least) natural to expect os.chown() to
>behave similarly; but that's not the case.
>
>I can see os module wants to be a thin wrapper around OS syscalls and
>chown(2) accepts only uid/gid as input, so what would be best: extend
>os.chown() or provide a chown() function in shutil module for this
>purpose?

I think it would be a nice feature, and I can see the conflict.  OT1H you want
to keep os.chown() a thin wrapper, but OTOH you'd rather not have to add a
new, arguably more difficult to discover, function.  Given those two choices,
I still think I'd come down on adding a new function and shutil.chown() seems
an appropriate place for it.

Cheers,
-Barry



signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader

2011-05-25 Thread M.-A. Lemburg 
Victor Stinner wrote:
> Le mercredi 25 mai 2011 à 11:38 +0200, M.-A. Lemburg a écrit :
>> You are missing the point: we have StreamReader and StreamWriter APIs
>> on codecs to allow each codecs to implement more efficient ways of
>> encoding and decoding streams.
>>
>> Examples of such optimizations are reading the stream in
>> chunks that can be decoded in one piece, or writing to the stream
>> in a way that doesn't generate encoding state problems on the
>> receiving end by ending transmission half-way through a
>> shift block.
>>
>> ...
>>
>> We don't have many such specialized implementations in the stdlib,
>> but this doesn't mean that there's no use for them. It
>> just means that developers and users are simply unaware of the
>> possibilities opened by these stateful stream APIs.
> 
> Does at least one codec implement such implementation in its
> StreamReader or StreamWriter class? And can't we implement such
> optimization in incremental encoders and decoders (or in TextIOWrapper)?

I don't see how, since you need control over the file API methods
in order to implement such optimizations. OTOH, adding lots of
special cases to TextIOWrapper isn't a good either, since these
optimizations would then only trigger for a small number of
codecs and completely leave out 3rd party codecs.

> I checked all multibyte codecs (UTF and CJK codecs) and I don't see any
> of such optimization. UTF codecs handle the BOM, but don't have anything
> looking like an optimization. CJK codecs use multibytecodec,
> MultibyteStreamReader and MultibyteStreamWriter, which don't look to be
> optimized. But I missed maybe something?

No, you haven't missed such per-codec optimizations. The base classes
implement general purpose support for reading from streams in
chunks, but the support isn't optimized per codec.

For UTF-16 it would e.g. make sense to always read data in blocks
with even sizes, removing the trial-and-error decoding and extra
buffering currently done by the base classes. For UTF-32, the
blocks should have size % 4 == 0.

For UTF-8 (and other variable length encodings) it would make
sense looking at the end of the (bytes) data read from the
stream to see whether a complete code point was read or not,
rather than simply running the decoder on the complete data
set, only to find that a few bytes at the end are missing.

For single character encodings, it would make sense to prefetch
data in big chunks and skip all the trial and error decoding
implemented by the base classes to address the above problem
with variable length encodings.

Finally, all this could be implemented in C, reducing the
Python call overhead dramatically.

> TextIOWrapper has an advanced buffer algorithm to prefetch (readahead)
> some bytes at each read to speed up small read. It is difficult to
> implement such algorithm, but it's done and it works.
> 
> --
> 
> Ok, let's stop to speak about theorical optimizations, and let's do a
> benchmark to compare codecs and the io modules on reading files!

That's somewhat unfair: TextIOWrapper is implemented in C,
whereas the StreamReader/Writer subclasses used by the
codecs are written in Python.

A fair comparison would use the Python implementation of
TextIOWrapper.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 25 2011)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2011-05-23: Released eGenix mx Base 3.2.0  http://python.egenix.com/
2011-05-25: Released mxODBC 3.1.1  http://python.egenix.com/
2011-06-20: EuroPython 2011, Florence, Italy   26 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Antoine Pitrou 
On Wed, 25 May 2011 09:41:46 -0400
Barry Warsaw  wrote:

> On May 25, 2011, at 10:24 AM, Sandro Tosi wrote:
> 
> >before opening an issue to track the request, I'd like to ask advice
> >here about this: extend os.chown() to accept even user/group names
> >instead of just uid and gid.
> >
> >On a Unix system, you can call chown command passing either id or
> >names, so it seems (to me at least) natural to expect os.chown() to
> >behave similarly; but that's not the case.
> >
> >I can see os module wants to be a thin wrapper around OS syscalls and
> >chown(2) accepts only uid/gid as input, so what would be best: extend
> >os.chown() or provide a chown() function in shutil module for this
> >purpose?
> 
> I think it would be a nice feature, and I can see the conflict.  OT1H you want
> to keep os.chown() a thin wrapper, but OTOH you'd rather not have to add a
> new, arguably more difficult to discover, function.  Given those two choices,
> I still think I'd come down on adding a new function and shutil.chown() seems
> an appropriate place for it.

+1 for shutil.chown().

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Dirkjan Ochtman 
On Wed, May 25, 2011 at 15:41, Barry Warsaw  wrote:
> I think it would be a nice feature, and I can see the conflict.  OT1H you want
> to keep os.chown() a thin wrapper, but OTOH you'd rather not have to add a
> new, arguably more difficult to discover, function.  Given those two choices,
> I still think I'd come down on adding a new function and shutil.chown() seems
> an appropriate place for it.

Right. Please add a mention of shutil.chown() to the os.chown() docs, though.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Barry Warsaw 
On May 25, 2011, at 04:15 PM, Dirkjan Ochtman wrote:

>Right. Please add a mention of shutil.chown() to the os.chown() docs, though.

Brilliant!

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader

2011-05-25 Thread Victor Stinner 
Le mercredi 25 mai 2011 à 15:43 +0200, M.-A. Lemburg a écrit :
> For UTF-16 it would e.g. make sense to always read data in blocks
> with even sizes, removing the trial-and-error decoding and extra
> buffering currently done by the base classes. For UTF-32, the
> blocks should have size % 4 == 0.
>
> For UTF-8 (and other variable length encodings) it would make
> sense looking at the end of the (bytes) data read from the
> stream to see whether a complete code point was read or not,
> rather than simply running the decoder on the complete data
> set, only to find that a few bytes at the end are missing.

I think that the readahead algorithm is much more faster than trying to
avoid partial input, and it's not a problem to have partial input if you
use an incremental decoder.

> For single character encodings, it would make sense to prefetch
> data in big chunks and skip all the trial and error decoding
> implemented by the base classes to address the above problem
> with variable length encodings.

TextIOWrapper implements this optimization using its readahead
algorithm.

> That's somewhat unfair: TextIOWrapper is implemented in C,
> whereas the StreamReader/Writer subclasses used by the
> codecs are written in Python.
> 
> A fair comparison would use the Python implementation of
> TextIOWrapper.

Do you mean that you would like to reimplement codecs in C? It is not
revelant to compare codecs and _pyio, because codecs reuses
BufferedReader (of the io module, not of the _pyio module), and io is
the main I/O module of Python 3.

But well, as you want, here is a benchmark comparing:
   _pyio.TextIOWrapper(io.open(filename, 'rb'), encoding)
and 
codecs.open(filename, encoding)

The only change with my previous bench.py script is the test_io()
function :

def test_io(test_func, chunk_size):
with open(FILENAME, 'rb') as buffered:
f = _pyio.TextIOWrapper(buffered, ENCODING)
test_file(f, test_func, chunk_size)
f.close()


(1) Decode Objects/unicodeobject.c (317336 characters) from utf-8

test_io.readline(): 1193.4 ms
test_codecs.readline(): 1267.9 ms
-> codecs 6% slower than io

test_io.read(1): 21696.4 ms
test_codecs.read(1): 36027.2 ms
-> codecs 66% slower than io

test_io.read(100): 3080.7 ms
test_codecs.read(100): 3901.7 ms
-> codecs 27% slower than io

test_io.read(): 3991.0 ms
test_codecs.read(): 1736.9 ms
-> codecs 130% FASTER than io


(2) Decode README (6613 characters) from ascii

test_io.readline(): 678.1 ms
test_codecs.readline(): 760.5 ms
-> codecs 12% slower than io

test_io.read(1): 13533.2 ms
test_codecs.read(1): 21900.0 ms
-> codecs 62% slower than io

test_io.read(100): 2663.1 ms
test_codecs.read(100): 3270.1 ms
-> codecs 23% slower than io

test_io.read(): 6769.1 ms
test_codecs.read(): 3919.6 ms
-> codecs 73% FASTER than io


(3) Decode Lib/test/cjkencodings/gb18030.txt (501 characters) from
gb18030

test_io.readline(): 38.9 ms
test_codecs.readline(): 15.1 ms
-> codecs 157% FASTER than io

test_io.read(1): 369.8 ms
test_codecs.read(1): 302.2 ms
-> codecs 22% FASTER than io

test_io.read(100): 258.2 ms
test_codecs.read(100): 155.1 ms
-> codecs 67% FASTER than io

test_io.read(): 1803.2 ms
test_codecs.read(): 1002.9 ms
-> codecs 80% FASTER than io


_pyio.TextIOWrapper is faster than codecs.StreamReader for readline(),
read(1) and read(100), with ASCII and UTF-8. It is slower for gb18030.

As in the io vs codecs benchmark, codecs.StreamReader is always faster
than _pyio.TextIOWrapper for read().

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader

2011-05-25 Thread Victor Stinner 
Le mercredi 25 mai 2011 à 13:10 +0200, Victor Stinner a écrit :
> codecs is always faster (between 1.07 and 1.15 times faster than io) to
> read the whole content of file using read(-1). Something should maybe be
> optimized in TextIOWrapper.read() ;-)

Oh, I understood: it's maybe the universal newline mode of TextIOWrapper
was enabled. If you disable is using open(..., newline='\n'), io and
codecs run at the same speed to read the whole content of the file
(f.read()).

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl

2011-05-25 Thread Terry Reedy 

On 5/25/2011 1:09 AM, Nick Coghlan wrote:


The more important feature here is that it is exposing *OpenSSL's*
random number generation, rather than our own.


I agree, thought from a different stance, I think. The issue is whether 
we should 'automatically' expose everything is a wrapped library, even 
if it duplicates existing functions. I think not. But in this case, at 
least one of the two functions is sufficiently different, and the newest 
doc patches clarify the situation.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Charles-François Natali 
While we're at it, adding a "recursive" argument to this shutil.chown
could also be useful.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Fix closes issue #11109 - socketserver.ForkingMixIn leaves zombies, also fails

2011-05-25 Thread Antoine Pitrou 
On Wed, 25 May 2011 18:26:46 +0200
senthil.kumaran  wrote:
> 
> A new method called service_action is made available in BaseServer, called by
> serve_forever loop. This useful in cases where Mixins can use it for cleanup
> action. ForkingMixin class uses service_action to collect the zombie child
> processes. Initial Patch by Justin Wark.

Is it reasonable, performance-wise, to do this at every iteration of
the loop (that is, at every incoming connection)?

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Victor Stinner 
Le mercredi 25 mai 2011 à 18:46 +0200, Charles-François Natali a écrit :
> While we're at it, adding a "recursive" argument to this shutil.chown
> could also be useful.

I don't like the idea of a recursive flag. I would prefer a "map-like"
function to "apply" a function on all files of a directory. Something
like shutil.apply_recursive(shutil.chown)...

... maybe with options to choose between deep-first search and
breadth-first search, filter (filenames, file size, files only,
directories only, other attributes?), directory before files (may be
need for chmod(0o000)), etc.

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Eric Smith 
On 5/25/2011 1:17 PM, Victor Stinner wrote:
> Le mercredi 25 mai 2011 à 18:46 +0200, Charles-François Natali a écrit :
>> While we're at it, adding a "recursive" argument to this shutil.chown
>> could also be useful.
> 
> I don't like the idea of a recursive flag. I would prefer a "map-like"
> function to "apply" a function on all files of a directory. Something
> like shutil.apply_recursive(shutil.chown)...
> 
> ... maybe with options to choose between deep-first search and
> breadth-first search, filter (filenames, file size, files only,
> directories only, other attributes?), directory before files (may be
> need for chmod(0o000)), etc.

You can do all of this with an appropriate application of os.walk().

Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Petri Lehtinen 
Victor Stinner wrote:
> Le mercredi 25 mai 2011 à 18:46 +0200, Charles-François Natali a écrit :
> > While we're at it, adding a "recursive" argument to this shutil.chown
> > could also be useful.
> 
> I don't like the idea of a recursive flag. I would prefer a "map-like"
> function to "apply" a function on all files of a directory. Something
> like shutil.apply_recursive(shutil.chown)...

FWIW, the chown program (in GNU coreutils at least) has a -R flag for
recursive operation, and I've found it *extremely* useful on many
situations.

Petri
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 release schedule posted

2011-05-25 Thread Michael Foord 

On 26/03/2011 00:33, Laurens Van Houtven wrote:
On Thu, Mar 24, 2011 at 12:18 AM, Thomas Wouters > wrote:


It ended up that Jim Fulton is actually writing the PEP (with
input from Twisted people and others.)

-- 
Thomas Wouters mailto:[email protected]>>


Hi! I'm a .signature virus! copy me into your .signature file to
help me spread!


Well, if help is still needed I'll gladly chip in. It's not  that I'm 
not interested in doing it -- it's just that I don't know who's 
supposed to or who's working on it :)




Hey lvh,

It's worth following this up. If Jim Fulton hasn't had time to move this 
forward and you have the bandwidth to work on it then it would be great 
to see some action.


All the best,

Michael Foord


--
cheers
lvh


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Charles-François Natali 
>> While we're at it, adding a "recursive" argument to this shutil.chown
>> could also be useful.
>
> I don't like the idea of a recursive flag. I would prefer a "map-like"
> function to "apply" a function on all files of a directory. Something
> like shutil.apply_recursive(shutil.chown)...
>

I was also thinking about this possibility.
The advantage is that we could factor-out the recursive walk logic to
make it available for other functions (chown, chmod...).
It doesn't map well to the Unix command, though.

> You can do all of this with an appropriate application of os.walk().

Then, I wonder why shutil.copytree and shutil.rmtree are provided.
Recursive rm/copy/chown/chmod are extremely useful in system
administration scripts. Furthermore, it's not as simple as it seems
because of symlinks, see for example http://bugs.python.org/issue4489
.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Fix closes issue #11109 - socketserver.ForkingMixIn leaves zombies, also fails

2011-05-25 Thread Charles-François Natali 
>> A new method called service_action is made available in BaseServer, called by
>> serve_forever loop. This useful in cases where Mixins can use it for cleanup
>> action. ForkingMixin class uses service_action to collect the zombie child
>> processes. Initial Patch by Justin Wark.
>
> Is it reasonable, performance-wise, to do this at every iteration of
> the loop (that is, at every incoming connection)?
>

I haven't measured it, but it's O(N) where N is the number of children.
It should be possible to optimize this by putting all the children in
a process group (the other advantage is that we wouldn't wait()
children not spawned by socketserver).

cf
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] multibytecodex

2011-05-25 Thread Laura Creighton 

This just in from pypy-dev.  I am reposting it here because I
am fairly certain that nobody on the pypy-dev mailing list
uses the multibytecodex, but there has got to be at least one
person here who does.

Please reply to the pypy-dev article, not here, or mail to [email protected]
if you are not on the pypy-dev mailing list (but have delivery turned off
as many of you do.)

Thank you,
Laura

--- Forwarded Message

From: Armin Rigo 
Date: Wed, 25 May 2011 21:39:35 +0200
To: [email protected]
Subject: [pypy-dev] multibytecodec: missing features


Hi all,

Here are the missing features in multibytecodec:

* support for ``errors !=3D "strict"''.

* classes MultibyteIncrementalEncoder, MultibyteIncrementalDecoder,
MultibyteStreamReader and MultibyteStreamWriter.

One reason I didn't implement the classes yet is that I couldn't
understand two points in how they are supposed to work.  But it seems
that there are really two bugs, as I've been pointed to:
http://bugs.python.org/issue12100 and
http://bugs.python.org/issue12171 .  So the question is if we should
be bug-compatible with Python 2.7 or if we should instead implement
some fixed version.

I suppose I'm rather for the fixed version, but I'd like to hear some
feedback from people that actually use multibytecodecs.  Also, I
wouldn't mind if someone would pick up the work and just do it, either
the classes or ``errors !=3D "strict"'' :-)


A bient=F4t,

Armin.
___
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev

--- End of Forwarded Message

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] multibytecodex

2011-05-25 Thread Victor Stinner 
Le mercredi 25 mai 2011 à 23:41 +0200, Laura Creighton a écrit :
> One reason I didn't implement the classes yet is that I couldn't
> understand two points in how they are supposed to work.  But it seems
> that there are really two bugs, as I've been pointed to:
> http://bugs.python.org/issue12100 and
> http://bugs.python.org/issue12171 .  So the question is if we should
> be bug-compatible with Python 2.7 or if we should instead implement
> some fixed version.

I fixed #12100 in Python 2.7, 3.1, 3.2, 3.3 yesterday.

I plan also to fix #12171 in these four versions, it should be done next
days.

> I suppose I'm rather for the fixed version, but I'd like to hear some
> feedback from people that actually use multibytecodecs.

Both bugs are related to encoders. I don't think that anyone is using
Python CJK codecs to encode text (because nobody noticed these bugs
before), but more likely to decode text.

Anyway, you should implement a codec without these *bugs*.

For your information, I added more tests to the CJK codecs (e.g. see
#12057), and I plan to add more tests next weeks. I plan also to fix
issue #12016, yet another CJK codec bug. You may want to wait until all
of these bugs are fixed before working on your own implementation, or
implement directly a version without all of these bugs, and then upgrade
the test suite.

> Also, I wouldn't mind if someone would pick up the work and just do it,
> either the classes or ``errors !=3D "strict"'' :-)

The support of error handlers different than strict is far from being
perfect. Issue #12016 is the main problem, but there are other minor
issues.

In some cases, invalid byte sequences are ignored even with the replace
error handler (whereas I expected U+FFFD characters). CJK codecs are
special because they use escape sequences (especially the ISO 2022
family): what should be done if a byte sequence looks like an escape
sequences, but it is not valid? Replace each byte by U+FFFD, or ignore
these bytes?

I'm trying to write tests "describing" the current behaviour, and then I
will maybe try to improve how invalid byte sequences are handled.

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Tim Delaney 
2011/5/26 Victor Stinner 

> Le mercredi 25 mai 2011 à 18:46 +0200, Charles-François Natali a écrit :
> > While we're at it, adding a "recursive" argument to this shutil.chown
> > could also be useful.
>
> I don't like the idea of a recursive flag. I would prefer a "map-like"
> function to "apply" a function on all files of a directory. Something
> like shutil.apply_recursive(shutil.chown)...
>
> ... maybe with options to choose between deep-first search and
> breadth-first search, filter (filenames, file size, files only,
> directories only, other attributes?), directory before files (may be
> need for chmod(0o000)), etc.


Pass an iterable to shutil.chown()? Then you could call it like:

shutil.chown(os.walk(path))

Then of course you have the difficulty of wanting to pass either an iterator
or a single path - probably prefer two functions e.g.:

shutil.chown(path)
shutil.chown_many(iter)

Tim Delaney
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Fix closes issue #11109 - socketserver.ForkingMixIn leaves zombies, also fails

2011-05-25 Thread Senthil Kumaran 

Antoine Pitrou wrote:
> >> A new method called service_action is made available in BaseServer, called 
> >> by
> >> serve_forever loop. This useful in cases where Mixins can use it for 
> >> cleanup
> >> action. ForkingMixin class uses service_action to collect the zombie child
> >> processes. Initial Patch by Justin Wark.
> >
> > Is it reasonable, performance-wise, to do this at every iteration of
> > the loop (that is, at every incoming connection)?

If not here, the call was being done at the process_request level when
creating a new child process and the wait would have been there. I am
not sure, how much performance different (lag) this aggressive
collection can bring.

Charles-François Natali wrote:

> I haven't measured it, but it's O(N) where N is the number of children.
> It should be possible to optimize this by putting all the children in
> a process group (the other advantage is that we wouldn't wait()
> children not spawned by socketserver).

+1. This is definitely a good idea. The change needs to be done in the
collection_children routine which tries to wait for all children to
finish instead of just the ones forked by the socketserver.
Shall raise ticket for this.

-- 
Senthil

Although the moon is smaller than the earth, it is farther away.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Nick Coghlan 
2011/5/26 Charles-François Natali :
> Then, I wonder why shutil.copytree and shutil.rmtree are provided.
> Recursive rm/copy/chown/chmod are extremely useful in system
> administration scripts. Furthermore, it's not as simple as it seems
> because of symlinks, see for example http://bugs.python.org/issue4489

Rather than a fixed binary flag, I would suggest following the
precedent of copytree and rmtree, and provide recursive functionality
as a separate shutil function (i.e. shutil.chmodtree,
shutil.chowntree).

As noted, while these *can* be written manually, it is convenient to
have the logic for handling symlinks dealt with for you, as well as
not having to look up the particular incantation for correctly linking
os.walk and the relevant operations.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extending os.chown() to accept user/group names

2011-05-25 Thread Petri Lehtinen 
Nick Coghlan wrote:
> 2011/5/26 Charles-François Natali :
> > Then, I wonder why shutil.copytree and shutil.rmtree are provided.
> > Recursive rm/copy/chown/chmod are extremely useful in system
> > administration scripts. Furthermore, it's not as simple as it seems
> > because of symlinks, see for example http://bugs.python.org/issue4489
> 
> Rather than a fixed binary flag, I would suggest following the
> precedent of copytree and rmtree, and provide recursive functionality
> as a separate shutil function (i.e. shutil.chmodtree,
> shutil.chowntree).

+1

> As noted, while these *can* be written manually, it is convenient to
> have the logic for handling symlinks dealt with for you, as well as
> not having to look up the particular incantation for correctly linking
> os.walk and the relevant operations.

This is exactly what I meant when saying that the -R option to chown
and chmod shell commands is useful. I *could* do it without them, but
writing the same logic every time with error handling would be
cumbersome.

Petri
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com