headers
Greg Ewing | 1 Jul 2004 04:17
Picon
Picon
Favicon

RE: PEP 276 (simple iterator for ints)

"Chermside, Michael" <mchermside <at> ingdirect.com>:

>     >>> for i in len(myList):
>     ...     doSomethingWithIndexes(i)
> 
> is simple and elegant.

IMO it would be clearer, and equally elegant, to write
this as something like

  for i in indices(myList):
    ...

which is easily accomplished with the aid of a suitable
definition for indices(). No language changes needed.

I suspect most people other than number theorists would
find the concept of a set of integers being contained
in another integer quite wierd.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg <at> cosc.canterbury.ac.nz	   +--------------------------------------+

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tim Peters | 1 Jul 2004 04:55
Picon

Re: SHA-256 module

[Gregory P. Smith]
> ...
>  the bsddb module includes encrypted database support in it (unless the
> windows packager has been building the non crypto version of the library
> distributed by sleepycat; i haven't checked).

The Windows installer does ship the non-crypto version of Sleepcat
Berkeley DB.  There was no debate about that, it was just the easiest
thing to do at the time.  For the same "reason", the Windows installer
doesn't ship any of the auxiliary BDB tools either ... it's the
laziest packaging of bsddb that allowed the test suite to pass. 
Improving this story.would probably require a volunteer who actually
knows something about BDB.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 3 comments |
headers
Bill Janssen | 1 Jul 2004 05:21
Favicon

Re: Allowing u.encode() to return non-strings

Tim,

Thanks for pointing this out.  I find it very hard to know that from
any of the documentation, unless of course you already know it, in
which case you don't need the documentation :-).  In particular, I'd
suggest adding some text to the documentation on codecs.open() which
points out that read and readlines and friends will in fact return
Unicode objects.

I assume, though, that the args to "read()" and friends are still
about bytes.

>> Any file that is not explicitly opened as binary (with the 'b' flag
>> (and, by the way, why isn't the 'b' flag the default for file opening?

> Because it isn't in C.

That's probably why Python doesn't have list comprehensions, either :-).

Bill

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 1 comment |
headers
Tim Peters | 1 Jul 2004 05:46
Picon

Re: making weakref.ref objects subclassable

[Fred L. Drake, Jr.]
> I'm planning to commit a patch (http://www.python.org/sf/983019) that
> makes weak references subclassable.  This includes the following changes:
> 
> ...
> - the cyclic garbage detector will be affected by the change to
> PyWeakref_CheckRef(); it will potentially call issubtype() for objects in
> the unreachable list that do not have finalizers (in the
> move_troublemakers() function).  This should only happen for weakref
> objects which are not of one of the "standard" three types (ref, proxy,
> and callable proxy).

I think the new expense is actually that PyType_IsSubtype() will get called 
once per collection on each scanned object that is unreachable, doesn't have

a finalizer, and isn't of one of the three std weakref types (not just for 
weakref objects that aren't of one of the std weakref types -- it's all 
objects that aren't of one of the std weakref types).

But that isn't scary.  An object is typically unreachable exactly once in
its lifetime (so far as gc is concerned), so it's one measly extra 
PyType_IsSubtype() call over the lifetime of each non-std-weakref container 
object without a finalizer, and that is reclaimed by virtue of ending up in
a dead cycle, or reachable only from a dead cycle.  Most container objects 
continue to get reclaimed via refcounting (the patch has no effect on that),

so are never found to be unreachable by gc, and so never incur the trivial-
anyway new call to PyType_IsSubtype().

> ...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred Drake | 1 Jul 2004 06:01

Re: making weakref.ref objects subclassable

On Wednesday 30 June 2004 11:46 pm, Tim Peters wrote:
 > Well, there is no change to gcmodule.c, except for the indirect change in
 > what the PyWeakref_Check() macro expands to.  The risks with weakrefs

The change in the macro expansion is exactly what I was referring to; not a 
source change, but a real change none the less.

 > For reasons given above, I believe gc performance will be virtually
 > unchanged for almost all programs.

That was my conclusion as well.  Empirical evidence with the Zope 3 test suite 
suggests that's right.  If anyone has an application that would be 
meaningfully affected by this change, I'd be rather surprised, and would 
appreciate hearing about it.

  -Fred

--

-- 
Fred L. Drake, Jr.  <fred at zope.com>
Zope Corporation

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 1 comment |
headers
Tim Peters | 1 Jul 2004 06:12
Picon

Re: Version 3 Proposal: thread-local data

[Jim]
...
>         def __del__(self):
>             key = object.__getattribute__(self, '_local__key')
>             for thread in enumerate():
>                 if key in thread.__dict__:
>                     del thread.__dict__[key]

Note that a __del__ method should never reference a module global
"enumerate" in this case) -- it's all but certain to lead to "iteration over
non-sequence" Mystery Errors at Python shutdown time (due to module globals
getting "None'd out").  The conventional workaround is to give the class an
attribute initialized from the module global; e.g.,

class local(_localbase):
    _enumerate = threading.enumerate

    ...

    def __del__(self):
        ...
        for thread in self._enumerate():

The conventional workaround that doesn't work is to spell that

        for thread in local._enumerate():

instead; it doesn't work because "local" is also a module global.

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anthony Baxter | 1 Jul 2004 06:13
Picon

Re: Including translated doc strings in 2.4

Stephan Richter wrote:
> The standard directory for gettext files is "locales".

"locales", however, is a valid package name. I'd much prefer
that something going into lib/python2.4/ that is _not_ a package,
not have a name that _could_ be a package. And yes, I'm aware
that the very very old 'config' directory violates this rule -
but I don't think we can move that without breaking all the
old Makefile.pre.in-based installation scripts.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 1 comment |
headers
Tim Peters | 1 Jul 2004 06:15
Picon

RE: making weakref.ref objects subclassable

[Tim]
>> For reasons given above, I believe gc performance will be virtually
>> unchanged for almost all programs.

[Fred Drake]
> That was my conclusion as well.  Empirical evidence with the Zope 3 test
> suite suggests that's right.  If anyone has an application that would be
> meaningfully affected by this change, I'd be rather surprised, and would
> appreciate hearing about it.

For the reasons given before, that won't happen.  The analysis I gave was
based on a complete understanding of every gory detail of how Python's gc
works -- there's simply nothing risky about this change wrt gc performance.
Empirical validation is unnecessary <wink>.

If people want to surprise us, better they spend time writing nasty new
tests of weakref subclassing!

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Nick Coghlan | 1 Jul 2004 06:24
Picon
Picon

Re: PEP 276 (simple iterator for ints)

Greg Ewing wrote:

> "Chermside, Michael" <mchermside <at> ingdirect.com>:
> 
> 
>>    >>> for i in len(myList):
>>    ...     doSomethingWithIndexes(i)
>>
>>is simple and elegant.
> 
> 
> IMO it would be clearer, and equally elegant, to write
> this as something like
> 
>   for i in indices(myList):
>     ...
> 
> which is easily accomplished with the aid of a suitable
> definition for indices(). No language changes needed.

And I believe most of those use cases are better covered by enumerate() 
anyway.

Interesting that in the course of this discussion I've gone from 'nice 
idea' to 'no way!'

Cheers,
Nick.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Delaney, Timothy C (Timothy | 1 Jul 2004 06:28
Favicon

RE: PEP 276 (simple iterator for ints)

Nick Coghlan wrote:

> Interesting that in the course of this discussion I've gone from 'nice
> idea' to 'no way!'

That's exactly what happened to me when the PEP was first proposed. On
the face of it, it's a nice, simple, easily-understood thing. However,
when you think about the use cases, it starts looking more like a hack.

Tim Delaney

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |

Gmane