Re: [Python-Dev] Store x Load x --> DupStore
Michael Hudson <[EMAIL PROTECTED]> writes: >> Because there are CO_MAXBLOCKS * 12 bytes in there for the block >> stack. If there was no need for that, frames could perhaps be >> allocated via pymalloc. They only have around 100 bytes or so in >> them, apart from the blockstack and locals/value stack. > > What I'm trying is allocating the blockstack separately and see if two > pymallocs are cheaper than one malloc. This makes no difference at all, of course -- once timeit or pystone gets going the code path that actually allocates a new frame as opposed to popping one off the free list simply never gets executed. Duh! Cheers, mwh (and despite what the sigmonster implies, I wasn't drunk last night :) -- This is an off-the-top-of-the-head-and-not-quite-sober suggestion, so is probably technically laughable. I'll see how embarassed I feel tomorrow morning.-- Patrick Gosling, ucam.comp.misc ___ 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] Re: Welcome to the "Python-Dev" mailing list
hi,friends i am a python newbie but i used Java for about 5 years. when i saw python introduce in a famous magzine called <> in China, i am immediately absorbed by its pretty code. i hope i can use Python to do real development. regards! 2005-02-21 14:28:00 您在来信中写道： Welcome to the [email protected] mailing list! If you are a new subscriber, please take the time to introduce yourself briefly in your first post. It is appreciated if you lurk around for a while before posting! :-) Additional information on Python's development process can be found in the Python Developer's Guide: http://www.python.org/dev/ To post to this list, send your email to: [email protected] General information about the mailing list is at: http://mail.python.org/mailman/listinfo/python-dev If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://mail.python.org/mailman/options/python-dev/z_axis%40163.com You can also make such adjustments via email by sending a message to: [EMAIL PROTECTED] with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: zpython999 Normally, Mailman will remind you of your python.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. = = = = = = = = = = = = = = = = = = = = = = 致礼！ z-axis [EMAIL PROTECTED] 2005-02-21 ___ 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] UserString
> > Anyway, can you explain why LBYL is bad? > > In the general case, it's bad because of a combination of issues. It > may violate "once, and only once!" -- the operations one needs to check > may basicaly duplicate the operations one then wants to perform. Apart > from wasted effort, it may happen that the situation changes between > the look and the leap (on an external file, or due perhaps to threading > or other reentrancy). It's often hard in the look to cover exactly the > set of prereq's you need for the leap -- e.g. I've often seen code such > as > if i < len(foo): > foo[i] = 24 > which breaks for i<-len(foo); the first time this happens the guard's > changed to 0<=i w/negative index; finally it stabilizes to the correct check, > -len(foo)<=i check that Python performs again when you then use foo[i]... just > cluttering code. The intermediate Pythonista's who's learned to code > "try: foo[i]=24 // except IndexError: pass" is much better off than the > one who's still striving to LBYL as he had (e.g.) when using C. > > Etc -- this is all very general and generic. Right. There are plenty of examples where LBYL is better, e.g. because there are too many different exceptions to catch, or they occur in too many places. One of my favorites is creating a directory if it doesn't already exist; I always use this LBYL-ish pattern: if not os.path.exists(dn): try: os.makedirs(dn) except os.error, err: ...log the error... because the specific exception for "it already exists" is quite subtle to pull out of the os.error structure. Taken to th extreme, the "LBYL is bad" meme would be an argument against my optional type checking proposal, which I doubt is what you want. So, I'd like to take a much more balanced view on LBYL. > I had convinced myself that strings were a special case worth singling > out, via isinstance and basestring, just as (say) dictionaries are > singled out quite differently by metods such as get... I may well have > been too superficial in this conclusion. I think there are lots of situations where the desire to special-case strings is legitimate. > >> Then you would be able to test whether something is sequence-like > >> by the presence of __getitem__ or __iter__ methods, without > >> getting tripped up by strings. > > > > There would be other ways to get out of this dilemma; we could > > introduce a char type, for example. Also, strings might be > > recognizable by other means, e.g. the presence of a lower() method or > > some other characteristic method that doesn't apply to sequence in > > general. > > Sure, there would many possibilities. > > > (To Alex: leaving transform() out of the string interface seems to me > > the simplest solution.) > > I guess you mean translate. Yes, that would probably be simplest. Right. BTW, there's *still* no sign from a PEP 246 rewrite. Maybe someone could offer Clark a hand? (Last time I inquired he was recovering from a week of illness.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Store x Load x --> DupStore
> Where are the attempts to speed up function/method calls? That's an > area where we could *really* use a breakthrough... At one time you had entertained treating some of the builtin calls as fixed. Is that something you want to go forward with? It would entail a "from __future__" and transition period. It would not be hard to take code like "return len(alist)" and transform it from: 2 0 LOAD_GLOBAL 0 (len) 3 LOAD_FAST0 (alist) 6 CALL_FUNCTION1 9 RETURN_VALUE to: 2 0 LOAD_FAST0 (alist) 3 OBJECT_LEN 4 RETURN_VALUE Some functions already have a custom opcode that cannot be used unless we freeze the meaning of the function name: repr --> UNARY_CONVERT --> PyObject_Repr iter --> GET_ITER --> PyObject_GetIter Alternately, functions could be served by a table of known, fixed functions: 2 0 LOAD_FAST0 (alist) 3 CALL_DEDICATED 0 (PyObject_Len) 6 RETURN_VALUE where the dispatch table is something like: [PyObject_Len, PyObject_Repr, PyObject_IsInstance, PyObject_IsTrue, PyObject_GetIter, ...]. Of course, none of these offer a big boost and there is some loss of dynamic behavior. Raymond ___ 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] UserString
On Mon, 2005-02-21 at 11:15, Guido van Rossum wrote: > Right. There are plenty of examples where LBYL is better, e.g. because > there are too many different exceptions to catch, or they occur in too > many places. One of my favorites is creating a directory if it doesn't > already exist; I always use this LBYL-ish pattern: > > if not os.path.exists(dn): > try: >os.makedirs(dn) > except os.error, err: >...log the error... > > because the specific exception for "it already exists" is quite subtle > to pull out of the os.error structure. Really? I do this kind of thing all the time: import os import errno try: os.makedirs(dn) except OSError, e: if e.errno <> errno.EEXIST: raise -Barry signature.asc Description: This is a digitally signed message part ___ 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] textwrap wordsep_re
Hi,
textwrap.fill() is awesome.
Except when the string to wrap contains dates -- which I would
like not to be broken. In general I think wordsep_re can be
smarter about what it decides are hyphenated words.
For example, this code:
print textwrap.fill('aa 2005-02-21', 18)
produces:
aa 2005-
02-21
A slightly tweaked wordsep_re:
textwrap.TextWrapper.wordsep_re = \
re.compile(r'(\s+|' # any whitespace
r'[^\s\w]*\w+[a-zA-Z]-(?=[a-zA-Z]\w+)|' # hyphenated words
r'(?<=[\w\!\"\'\&\.\,\?])-{2,}(?=\w))') # em-dash
print textwrap.fill('aa 2005-02-21', 18)
behaves better:
aa
2005-02-21
What do you think about changing the default wordsep_re?
--
Karl 2005-02-21 17:39
___
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
