Re: [Python-Dev] LOAD_SELF and SELF_ATTR opcodes

[Martin v. Löwis]

[EMAIL PROTECTED] wrote:
> (Send it to Raymond H.  He'll probably sneak it in when Martin's not
> looking. )

I'm not personally objecting :-) I just recall that there was that kind
of objection when I proposed similar changes myself a couple of years
ago.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).

[Reinhold Birkenfeld]

Martin Blais wrote:
> On 10/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> Martin Blais <[EMAIL PROTECTED]> writes:
>>
>> > How hard would that be to implement?
>>
>> import sys
>> reload(sys)
>> sys.setdefaultencoding('undefined')
> 
> Hmmm any particular reason for the call to reload() here?

Yes. setdefaultencoding() is removed from sys by site.py. To get it
again you must reload sys.

Reinhold

-- 
Mail address is perfectly valid!

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

Re: [Python-Dev] LOAD_SELF and SELF_ATTR opcodes

[Michael Hudson]

"Phillip J. Eby" <[EMAIL PROTECTED]> writes:

> Indeed, even pystone doesn't do much attribute access on the first argument 
> of most of its functions, especially not those in inner loops.  Only 
> Proc1() and the Record.copy() method do anything that would be helped by 
> SELF_ATTR.  But it seems to me that this is very unusual for 
> object-oriented code, and that more common uses of Python should be helped 
> a lot more by this.

Is it that unusual though?  I don't think it's that unreasonable to
suppose that 'typical smalltalk code' sends messages to self a good
deal more often than 'typical python code'.  I'm not saying that this
*is* the case, but my intuition is that it might be (not all Python
code is that object oriented, after all).

Cheers,
mwh

-- 
  The source passes lint without any complaint (if invoked with
  >/dev/null).-- Daniel Fischer, http://www.ioccc.org/1998/df.hint
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Simplify lnotab? (AST branch update)

[Greg Ewing]

Phillip J. Eby wrote:
> At 08:07 PM 10/14/2005 +1300, Greg Ewing wrote:
> 
>> More straightforwardly, the second table could just be a
>> bytecode -> file number mapping.
> 
> That would use more space in any case involving multiple files.

Are you sure? Most of the time you're going to have
chunks of contiguous lines coming from the same file,
and the bytecode->filename table will only have an
entry for the first bytecode of the first line of
each chunk. I don't see how that works out differently
from mapping bytecodes->lines and then lines->files.

> That'd probably work.

Greg


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

Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)

[Fredrik Lundh]

Antoine Pitrou wrote:

> > unfortunately, this standard seem to result in generic "spamtools" modules
> > into which people throw everything that's even remotely related to "spam",
> > followed by complaints about bloat and performance from users, followed by
> > various more or less stupid attempts to implement lazy loading of hidden in-
> > ternal modules, followed by more complaints from users who no longer has
> > a clear view of what's really going on in there...
>
> BTW, what's the performance problem in importing unnecessary stuff
> (assuming pyc files are already generated) ?

larger modules can easily take 0.1-0.2 seconds to import (at least if they
use enough external dependencies).  that may not be a lot of time in itself,
but it can result in several seconds extra startup time for a larger program.

importing unneeded modules also add to the process size, of course.  you
don't need to import too many modules to gobble up a couple of megabytes...





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

Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)

[skip]

>> BTW, what's the performance problem in importing unnecessary stuff
>> (assuming pyc files are already generated) ?

Fredrik> larger modules can easily take 0.1-0.2 seconds to import (at
Fredrik> least if they use enough external dependencies).

I wish it was that short.  At work we use lots of SWIG-wrapped C++
libraries.  Whole lotta dynamic linking goin' on...  In our case I don't
think autoloading would help all that much.  We actually use all that stuff.
The best we could do would be to defer the link step for a couple seconds.

Skip

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

Re: [Python-Dev] LOAD_SELF and SELF_ATTR opcodes

[Phillip J. Eby]

At 09:17 AM 10/15/2005 +0100, Michael Hudson wrote:
>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>
> > Indeed, even pystone doesn't do much attribute access on the first 
> argument
> > of most of its functions, especially not those in inner loops.  Only
> > Proc1() and the Record.copy() method do anything that would be helped by
> > SELF_ATTR.  But it seems to me that this is very unusual for
> > object-oriented code, and that more common uses of Python should be helped
> > a lot more by this.
>
>Is it that unusual though?  I don't think it's that unreasonable to
>suppose that 'typical smalltalk code' sends messages to self a good
>deal more often than 'typical python code'.  I'm not saying that this
>*is* the case, but my intuition is that it might be (not all Python
>code is that object oriented, after all).

Well, my greps on the stdlib suggest that about 50% of all lines doing 
attribute access, include an attribute access on 'self'.  So for the 
stdlib, it's darn common.  Plus, all functions benefit a tiny bit from 
faster access to their first argument via the LOAD_SELF opcode, which is 
what produced the roughly 2% improvement of parrotbench.

The overall performance question has more to do with whether any of those 
accesses to self or self attributes are in loops.  A person who's 
experienced at doing Python performance tuning will probably lift as many 
of them out of the innermost loops as possible, thereby lessening the 
impact of the change somewhat.  But someone who doesn't know to do that, or 
just hasn't done it yet, will get more benefit from the change, but not as 
much as they'd get by lifting out the attribute access.

Thus my guess is that it'll speed up "typical", un-tuned Python code by a 
few %, and is unlikely to slow anything down - even compilation.  (The 
compiler changes are extremely minimal and localized to the relevant 
bytecode emission points.)  Seems like a freebie, all in all.

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

Re: [Python-Dev] LOAD_SELF and SELF_ATTR opcodes

[Tim Delaney]

Tim Delaney wrote:

> that also binds all attribute accesses all the way down into a single
> constant call e.g.
>
>LOAD_FAST  0
>LOAD_ATTR  'a'
>LOAD_ATTR  'b'
>LOAD_ATTR  'c'
>LOAD_ATTR  'd'
>
> is bound to a single constant:
>
>LOAD_CONST  5

D'oh. I'm a moron - of course it can't do that. It'll do it for LOAD_GLOBAL 
followed by multiple LOAD_ATTR, and (I think) also for LOAD_NAME.

Tim Delaney 

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

Re: [Python-Dev] Unicode charmap decoders slow

[Tony Nelson]

I have put up a new, packaged version of my fast charmap module at
 .  Hopefully it is packaged properly
and works properly (it works on my FC3 Python 2.3.4 system).  This version
is over 5 times faster than the base codec according to Hye-Shik Chang's
benchmark (mostly from compiling it with -O3).

I bring it up here mostly because I mention in its docs that improved
faster charmap codecs are coming from the Python developers.  Is it OK to
say that, and have I said it right?  I'll take that out if you folks want.

I understand that my module is not favored by Martin v. Löwis, and I don't
advocate it becoming part of Python.  My web page and docs say that it may
be useful until Python has the faster codecs.  It allows changing the
mappings because that is part of the current semantics -- a new version of
Python can certainly change those semantics.

I want to thank you all for so quickly going to work on the problem of
making charmap codecs faster.  It's to the benefit of Python users
everywhere to have faster charmap codecs in Python.  Your quickness
impressed me.

BTW, Martin, if you care to, would you explain to me how a Trie would be
used for charmap encoding?  I know a couple of approaches, but I don't know
how to do it fast.  (I've never actually had the occasion to use a Trie.)

TonyN.:'   
  '  
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sourceforge CVS access

[Nick Coghlan]

Guido van Rossum wrote:
> You're in. Use it wisely. Let me know if there are things you still
> cannot do. (But I'm not used to being SF project admin any more; other
> admins may be able to help you quicker...)

Almost there - checking out over SSH failed to work. I checked the python SF 
admin page, and I still only have read access to the CVS repository. So if one 
of the SF admins could flip that last switch, that would be great :)

Regards,
Nick.

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

[Python-Dev] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  344 open ( +3) /  2955 closed ( +2) /  3299 total ( +5)
Bugs:  883 open ( -1) /  5341 closed (+20) /  6224 total (+19)
RFE :  201 open ( +5) /   187 closed ( +0) /   388 total ( +5)

New / Reopened Patches
__

Compiling and linking main() with C++ compiler  (2005-10-12)
   http://python.org/sf/1324762  opened by  Christoph Ludwig

Adding redblack tree to collections module  (2005-10-12)
   http://python.org/sf/1324770  opened by  Hye-Shik Chang

Letting "build_ext --libraries" take more than one lib  (2005-10-13)
   http://python.org/sf/1326113  opened by  Stephen A. Langer

VS NET 2003 Project Files contain per file compiler settings  (2005-10-15)
   http://python.org/sf/1327377  opened by  Juan-Carlos Lopez-Garcia

Static Windows Build fails to locate existing installation  (2005-10-15)
   http://python.org/sf/1327594  opened by  Doe, Baby

Patches Closed
__

Encoding alias "unicode-1-1-utf-7"  (2005-07-26)
   http://python.org/sf/1245379  closed by  doerwalter

Py_INCREF/Py_DECREF with magic constant demo  (2005-10-07)
   http://python.org/sf/1316653  closed by  rhamphoryncus

New / Reopened Bugs
___

irregular behavior within class using __setitem__  (2005-10-08)
CLOSED http://python.org/sf/1317376  opened by  capnSTABN

Missing Library Modules  (2005-10-09)
CLOSED http://python.org/sf/1321736  opened by  George LeCompte

Minor error in the Library Reference doc  (2005-10-10)
CLOSED http://python.org/sf/1323294  opened by  Colin J. Williams

getwindowsversion() constants in sys module  (2005-10-11)
   http://python.org/sf/1323369  opened by  Tony Meyer

C API doc for PySequence_Tuple duplicated  (2005-10-11)
CLOSED http://python.org/sf/1323739  opened by  George Yoshida

MSI installer not working  (2005-10-11)
CLOSED http://python.org/sf/1323810  opened by  Eric Rucker

ISO8859-9 broken  (2005-10-11)
   http://python.org/sf/1324237  opened by  Eray Ozkural

Curses module doesn't install on Solaris 2.8  (2005-10-12)
   http://python.org/sf/1324799  opened by  Andrew Koenig

"as" keyword sometimes highlighted in strings  (2005-10-12)
   http://python.org/sf/1325071  opened by  Artur de Sousa Rocha

binary code made by freeze results "unknown encoding"  (2005-10-13)
CLOSED http://python.org/sf/1325491  opened by  greatPython

Curses,h  (2005-10-13)
CLOSED http://python.org/sf/1325611  reopened by  rbrenner

Curses,h  (2005-10-13)
CLOSED http://python.org/sf/1325611  opened by  hafnium

Curses,h  (2005-10-13)
CLOSED http://python.org/sf/1325903  opened by  hafnium

traceback.py formats SyntaxError differently  (2005-10-13)
   http://python.org/sf/1326077  opened by  Neil Schemenauer

odd behaviour when making lists of lambda forms  (2005-10-13)
CLOSED http://python.org/sf/1326195  opened by  Johan Hidding

itertools.count wraps around after maxint  (2005-10-13)
   http://python.org/sf/1326277  opened by  paul rubin

pdb breaks programs which import from __main__  (2005-10-13)
   http://python.org/sf/1326406  opened by  Ilya Sandler

set.__getstate__ is not overriden  (2005-10-14)
   http://python.org/sf/1326448  opened by  George Sakkis

SIGALRM alarm signal kills interpreter  (2005-10-14)
CLOSED http://python.org/sf/1326841  opened by  paul rubin

wrong TypeError traceback in generator expressions  (2005-10-14)
   http://python.org/sf/1327110  opened by  Yusuke Shinyama

title() uppercases latin1 strings after accented letters  (2005-10-14)
CLOSED http://python.org/sf/1327233  opened by  Humberto Diógenes

Bugs Closed
___

Segmentation fault with invalid "coding"  (2005-10-07)
   http://python.org/sf/1316162  closed by  birkenfeld

irregular behavior within class using __setitem__  (2005-10-08)
   http://python.org/sf/1317376  closed by  ncoghlan

python.exe 2.4.2 compiled with VS2005 crashes  (2005-10-03)
   http://python.org/sf/1311784  closed by  loewis

2.4.2 make problems  (2005-10-03)
   http://python.org/sf/1311579  closed by  loewis

2.4.1 windows MSI has no _socket  (2005-09-24)
   http://python.org/sf/1302793  closed by  loewis

The _ssl build process for 2.3.5 is broken  (2005-09-16)
   http://python.org/sf/1292634  closed by  loewis

codecs.readline sometimes removes newline chars  (2005-04-02)
   http://python.org/sf/1175396  closed by  doerwalter

Missing Library Modules  (2005-10-09)
   http://python.org/sf/1321736  closed by  nnorwitz

inspect.getsourcelines() broken  (2005-10-07)
   http://python.org/sf/1315961  closed by  doerwalter

Minor error in the Library Reference doc  (2005-10-10)
   http://python.org/sf/1323294  closed by  nnorwitz

failure to build RPM on rhel 3  (2005-07-28)
   http://python.org/sf/1246900  closed by  jafo

C API doc for PySequence_Tuple duplicated  (2005-10-11)
   http://python.org/sf/1323739  closed by  nnorwitz

MSI installer not work

Re: [Python-Dev] Sourceforge CVS access

[Guido van Rossum]

Sobebody help Nick! This is beyond my SF-fu! :-(

On 10/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > You're in. Use it wisely. Let me know if there are things you still
> > cannot do. (But I'm not used to being SF project admin any more; other
> > admins may be able to help you quicker...)
>
> Almost there - checking out over SSH failed to work. I checked the python SF
> admin page, and I still only have read access to the CVS repository. So if one
> of the SF admins could flip that last switch, that would be great :)
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> ---
>  http://boredomandlaziness.blogspot.com
>
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sourceforge CVS access

[Guido van Rossum]

With Neal's help I've fixed Nick's permissions. Enjoy, Nick!

On 10/15/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Somebody help Nick! This is beyond my SF-fu! :-(
>
> On 10/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > You're in. Use it wisely. Let me know if there are things you still
> > > cannot do. (But I'm not used to being SF project admin any more; other
> > > admins may be able to help you quicker...)
> >
> > Almost there - checking out over SSH failed to work. I checked the python SF
> > admin page, and I still only have read access to the CVS repository. So if 
> > one
> > of the SF admins could flip that last switch, that would be great :)
> >
> > Regards,
> > Nick.
> >
> > --
> > Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> > ---
> >  http://boredomandlaziness.blogspot.com
> >
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sourceforge CVS access

[Nick Coghlan]

Guido van Rossum wrote:
> With Neal's help I've fixed Nick's permissions. Enjoy, Nick!

Thanks folks - it looks to be all good now.

Regards,
Nick.

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

[Python-Dev] AST branch merge status

[Jeremy Hylton]

I just merged the head back to the AST branch for what I hope is the
last time.  I plan to merge the branch to the head on Sunday evening. 
I'd appreciate it if folks could hold off on making changes on the
trunk until that merge happens.

If this is a non-trivial inconvenience for anyone, go ahead with the
changes but send me mail to  make sure that I don't lose the changes
when I do the merge.  Regardless, the compiler and Grammar are off
limits.  I'll blow away any changes you make there <0.1 wink>.

Jeremy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com