headers
John J Lee | 1 Jun 2004 01:24
Picon
Favicon

Re: cookielib

On Mon, 31 May 2004, [ISO-8859-1] "Martin v. Löwis" wrote:

> John J Lee wrote:
> > What next?
>
> I have applied the patch. Now, when I run regrtest, I get
[...snip debug output...]
>
> Can you provide a patch to suppress this output?

Whoops, I should never have had a Logger.addHandler() call in there,
should I?  I've attached a patch to the original SF patch.

John

_______________________________________________
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
Christian Tismer | 1 Jun 2004 01:49
Gravatar

Re: Why aren't more things weak referencable

Guido van Rossum wrote:

>>For strings at least, perhaps it is time to bite the bullet and
>>include weak reference support directly.  Weak reference support ups
>>the per string memory overhead from five words (ob_type, ob_refcnt,
>>ob_size, ob_shash, ob_sstate) to six.  The whole concept of weak
>>dictionaries is much more useful when strings can be used as keys
>>and/or values.
> 
> 
> Hmm... it is a high price to pay to add another word (*and* some extra
> code at dealloc time!) to every string object when very few apps need
> them and strings are about the most common data type.  And since
> they're immutable, what's the point of having weak refs to strings in
> the first place?  (Note that the original poster asked about
> *subclasses* of strings.)

Same here. I wouldnot vote to make strings or tuples or any other
tiny type weak-reffed in the first place.
Instead I would add the possible support to derived types, via
the __slot__ mechanism for instance.
There is a little coding necessary to make the generic code
handle the case of var-sized objects, but this is doable
and not very complicated.

This may be really needed or not. if we can create the rule
"every derived type *can* have weak-refs", this is simpler
to memorize than "well, most can, some cannot".

cheers -- chris
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Tismer | 1 Jun 2004 02:09
Gravatar

Re: Stackless Python

Martin v. Löwis wrote:

> Bob Ippolito wrote:
> 
>> I'm believe that map and filter are non-recursive

They have been. They can be, again, but why.

> Can you point me to the code that demonstrates this? Looking at 
> Stackless' src/Python/bltinmodule.c:builtin_map, I see
> 
>         for (i = 0; ; ++i) {
>         ...
>                 value = PyEval_CallObject(func, alist);
>                 ...
>         PyList_SetItem(result, i, value)
>         ...
>     }
> 
> which looks recursive to me.

Yes. trying to do a minimalistic approach, I dropped all
non-recursive implementations of non-trivial things (meaning
non-tail-recursive things) which were not absolutely necessary.
And since we have list comprehensions, map is no longer worth
being supported so much.

>> I am not sure about unicode encode/decode.  I don't think it's very 
>> common to do a tasklet switch in the middle of a unicode encode or 
>> decode, though :)
(Continue reading)

Permalink | Reply | 18 comments |
headers
Christian Tismer | 1 Jun 2004 02:16
Gravatar

Re: Stackless Python

Bob Ippolito wrote:

oops, ok, this need some words, still.

...

> Ok, then I am mistaken.  I thought I had seen a commit message that said 
> it was made non-recursive.  Either way, it's possible to write a 
> non-recursive version of map or anything else, it's just a bit of work.

I had that in 1.0, and I don't plan to do it again, although it
is simple, now.

...

> I don't think so, because the C stack should never run too deep, since 
> most code that is going to recurse (from the python-view) will do it 
> non-recursively (from the C-view).

You can create such situations. Until Stackless 3.0, it was possible
to do very deep explicit calls to the __call__ wrapper, for instance,
and wrappers were not supported.
Stackless 3.1 which is about to be announced has full support
for all slots and all methods by the machinery. Supported are
all tail-recursive calls (like __call__), because this is very cheap
to do. But it is possible to implement as many of special method
handlers and wrapper handlers as one wishes; I have the infrastructure
ready for this.

Anyway, for this rare artificial case, I have a check built in that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Peters | 1 Jun 2004 02:25
Picon

RE: doctest improvements

[Edward Loper]
> About a month and a half ago, I filed several patches for doctest, and
> they haven't gotten any comments; so I was wondering if anyone could look
> at them.

Jim Fulton and I intend to do some doctest work for 2.4, so feel free to
assign them to me.  I can't make time for it immediately, though.

> The most interesting is #933238, which addresses the often-noted problem
> that doctest can't handle blank lines.  It adds a special blank-line
> marker (currently "-"), which must be *dedented* with respect to the
> doctest block.

Fair warning that any gimmick weakening doctest's WYSIWYG guarantee is going
to be a hard sell if I'm the reviewer.  The business about blank lines is a
documented limitation of the design.  Limitations can indeed create
problems, but removing them can create other problems.  Making a doctest
reader learn a special "doctest markup language" is A Problem in this case.
Offhand, I'd be happier with an almost-self-evident (say)

    <blank line>

marker than with a cryptic

    _

"you have no hope of guessing what this means unless you scour the docs"
marker.  Dedenting is a clever idea, BTW.

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phillip J. Eby | 1 Jun 2004 02:37
Gravatar

Re: Stackless Python

At 02:09 AM 6/1/04 +0200, Christian Tismer wrote:
>Anyway, I don't really get the point.
>95% of Stackless is doing soft-switched stackless calls.
>Behavior is completely controllable. We can easily avoid
>any special C stack operation, by setting a flag that
>disallows it (easy to implement) or by excluding the hard
>switching stuff, completely (not an option now, but easy, too).

If soft-switching is portable (i.e. pure C, no assembly), and is exposed as 
a library module (so that Jython et al can avoid supporting it), then 
perhaps a PEP for adding that functionality to mainstream Python would be 
meaningful.

If that gets in, then the other 5% can always sneak in later via feature 
creep.  ;)  Or, more importantly (if I understand correctly), it could be 
separately distributed as an add-on for platforms that can support it.

_______________________________________________
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 | 15 comments |
headers
Edward Loper | 1 Jun 2004 02:41

Re: doctest improvements

Tim Peters wrote:
> [...] Making a doctest
> reader learn a special "doctest markup language" is A Problem in this case.
> Offhand, I'd be happier with an almost-self-evident (say)
> 
>     <blank line>

Perhaps you'd be happier with a different value of BLANKLINE_MARKER, 
then?  E.g. "blank>":

def test():
     r"""
     A different marker:

             >>> print 'a\n\nb'
             a
       blank>
             b
     """

Although this means that you have to indent the doctest quite far. 
Perhaps it would be better if I changed the patch so the marker doesn't 
need to dedented all the way?  E.g.:

def test():
     r"""
     A different marker:

         >>> print 'a\n\nb'
         a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bob Ippolito | 1 Jun 2004 02:49
Gravatar

Re: Stackless Python

On May 31, 2004, at 8:37 PM, Phillip J. Eby wrote:

> At 02:09 AM 6/1/04 +0200, Christian Tismer wrote:
>> Anyway, I don't really get the point.
>> 95% of Stackless is doing soft-switched stackless calls.
>> Behavior is completely controllable. We can easily avoid
>> any special C stack operation, by setting a flag that
>> disallows it (easy to implement) or by excluding the hard
>> switching stuff, completely (not an option now, but easy, too).
>
> If soft-switching is portable (i.e. pure C, no assembly), and is 
> exposed as a library module (so that Jython et al can avoid supporting 
> it), then perhaps a PEP for adding that functionality to mainstream 
> Python would be meaningful.

Soft switching needs to be implemented in a few key places of the 
interpreter itself or else Stackless would surely have been maintained 
as an extension module.  It is already pure C, no assembly or platform 
specific code.  Supporting the interface from Jython or IronPython 
should be possible, though at worst case each tasklet might actually be 
a new thread so it might not be terribly efficient... though it would 
work.

> If that gets in, then the other 5% can always sneak in later via 
> feature creep.  ;)  Or, more importantly (if I understand correctly), 
> it could be separately distributed as an add-on for platforms that can 
> support it.

Hard switching could be an add-on for platforms that support it..
(Continue reading)

Permalink | Reply | 2 comments |
headers
Edward Loper | 1 Jun 2004 02:51

anonymous cvs checkout

I'm having trouble checking out an anonymous copy of the Python CVS 
repository.  I tried the instructions from both the developer FAQ and 
the SF CVS page; and tried checking it out from debian, win2k, and OS X. 
  In all cases, I get an error that looks something like this:

     cvs server: cannot read file in mydbm_load_file: Input/output error
     cvs checkout: in directory .:
     cvs [checkout aborted]: *PANIC* administration files missing

A google search for "mydbm_load_file" didn't turn up anything useful. 
Anyone have an idea what's going wrong?  Thanks!

-Edward

(Here's a copy-paste of my shell session from debian, in case I'm doing 
something stupid:)

> [syse:~/data/programming] export CVSROOT=:pserver:anonymous <at> cvs.sourceforge.net:/cvsroot/python
> [syse:~/data/programming] cvs login
> Logging in to :pserver:anonymous <at> cvs.sourceforge.net:2401/cvsroot/python
> CVS password: 
> [syse:~/data/programming] cvs -z3 co python
> cvs server: cannot read file in mydbm_load_file: Input/output error
> cvs checkout: cannot read file in mydbm_load_file: Input/output error
> cvs checkout: warning: cannot write to history file /cvsroot/python/CVSROOT/history: Read-only file system
> cvs checkout: Updating python
> cvs checkout: failed to create lock directory for `/cvsroot/python/python'
(/cvsroot/python/python/#cvs.lock): Read-only file system
> cvs checkout: failed to obtain dir lock in repository `/cvsroot/python/python'
> cvs [checkout aborted]: read lock failed - giving up
(Continue reading)

Permalink | Reply | 1 comment |
headers
Norlin Abd Rahim | 1 Jun 2004 03:08
Picon

rounding problem

Hi,

I'm using python with zope. I used _.round and it seems like it is look
unstable. For example if i have one number, 1130.975 and rounded it to 2
decimal places, it will be 1130.97 and not 1130.98. But for certain numbers
it will rounded correctly if the last digit is 5. I even used fixedpoint.py
but still i've got the same problem. This applies only to numbers that have
digit 5 after the decimal places that needs to be rounded.

Any idea why?

TIA

Hi,
 
I'm using python with zope. I used _.round and it seems like it is look unstable. For example if i have one number, 1130.975 and rounded it to 2 decimal places, it will be 1130.97 and not 1130.98. But for certain numbers it will rounded correctly if the last digit is 5. I even used fixedpoint.py but still i've got the same problem. This applies only to numbers that have digit 5 after the decimal places that needs to be rounded.
 
Any idea why?
 
TIA
(Continue reading)

Permalink | Reply | 5 comments |

Gmane