Mailman 3 January 2008 - Python-ideas

Ideas towards GIL removal
by Greg Ewing July 18, 2008

July 18, 2008

I've been thinking about some ideas for reducing the amount of refcount adjustment that needs to be done, with a view to making GIL removal easier. 1) Permanent objects In a typical Python program there are many objects that are created at the beginning and exist for the life of the program -- classes, functions, literals, etc. Refcounting these is a waste of effort, since they're never going to go away. So perhaps there could be a way of marking such objects as "permanent" or "immortal". … [View More]

8 19

adopt an enum type for the standard library?
by Mark Summerfield April 12, 2008

April 12, 2008

AFAIK if you want enumerations you must either create your own, or use a third party module, or use namedtuple: Files = collections.namedtuple("Files", "minimum maximum")(1, 200) ... x = Files.minimum Using: MINIMUM, MAXIMUM = 1, 200 is often inconvenient, since you might have several different ones. Of course you could do: MIN_FILES = 1 MIN_DIRS = 0 Personally, I like enums and consider them to be a fundamental, but I don't like the above approaches. There is an … [View More]

10 14

non-Pre-PEP: Syntactic replacement of built-in types with user-defined callables (Take 2... fewer newlines!)
by Taro Jan. 31, 2008

Jan. 31, 2008

Hi all... again, Built-in types such as float, string, or list are first-class citizens in Python sourcefiles, having syntactic support: myfloat = 1.0 mystring = "my string" mylist = [1,2,4,8] mydict = {1:"a", 2:"b", 3:"c"} myset = {1,2,3} User-defined classes are second-class citizens, requiring data to be manually converted from a type: mydecimal = Decimal("1.00000000000000001") myrope = Rope("my rope") myblist = BList([1,2,4,8]) myordereddict = … [View More]OrderedDict((1,"a"), (2, "b"), (3, "c")) myfrozenset = frozenset([1,2,3]) If there's only one or two conversions needed in a file, then such conversion is not particularly burdensome, but if one wants to consistently use (say) decimals throughout a file then the ability to use a literal syntax makes for prettier source. Some languages have open types, allowing the addition of methods to built-in types. This is not considered desired behaviour for Python, since modifications made in one module can potentially affect code in other modules. A typedef is syntactic sugar to allow user-defined replacements to be treated as first-class citizens in code. They affect only the module in which they appear and do not modify the original type. To be typedeffable, something must be a builtin type, have a constant/syntactic representation, and be callable. Hence, typedeffable types would be limited to complex, dict, float, int, ?object?, list, slice, set, string, and tuple. No modification is made to __builtins__ or types, so conversion and/or reference to the original type is still possible. The syntax for a typedef is: from MODULE typedef ADAPTOR as TYPE OR typedef BUILTINADAPTOR as TYPE Syntactic constants of a given type are then wrapped with a call: ADAPTOR(SOURCELITERAL) where SOURCELITERAL is the string that appears in the sourcecode eg: from decimal typedef Decimal as float i = 1.000000000000000000000000000001 translates as: from decimal import Decimal as float i = Decimal("1.000000000000000000000000000001") Syntactic collections of a given type are always provided with a list of objects, eg: from decimal typedef Decimal as float from blist typedef BList as list b = [1.1, 4.2] translates as: from decimal import Decimal as float from blist import BList as list b = Blist([Decimal("1.1"), Decimal("4.2")]) and from collections typedef OrderedDict as dict d = {1:"a", 2:"b", 3:"c"} as: from collections import OrderedDict as dict d = OrderedDict([(1,"a"), (2,"b"), (3,"c")]) A typedef appears at the start of a module immediately after any __future__ imports. As no adaptors can be defined in a module before a typedef and typedefs are in no way a forward declaration, "typedef ADAPTOR as TYPE" only works for builtins, since to do otherwise would lead to one of two unpalatable options; either: a/ definition of adaptors would have to be allowed pre-typedef, which would allow them to be buried in code, making them far easier to miss; or b/ adaptors would be defined after the typedef, which means that you'd have to handle: typedef float as float def float(): pass or: typedef MyObject as object class MyObject(object): pass or: typedef myfloat as float x = 1.1 def myfloat(): pass It is true that if a valid typedef is made, the type can be redefined within the module; but the "consenting adults" rule applies -- it's possible to redefine str and float multiple times within a module as well, but that isn't recommended either (and the typedef at the top of the module at least indicates that non-standard behaviour is to be expected) It is a SyntaxError to typedef the same type more than once: from decimal typedef Decimal as float from types typedef FloatType as float #SyntaxError("Type 'float' already redefined.") Spelling: "typedef" is prettier than "pragma", and less likely to be in use than "use" but its behaviour is somewhat different from C's typedef, so perhaps another term may be preferred. Theoretical Performance Differences: Since a typedef is purely syntactic sugar, and all tranformational work would be done at compilation, running code should be no slower (there should be no new opcodes necessary) and by default no faster that performing manual conversion (though they may assist an optimisation). Unless optimisation magic is available, performance-critical code should be careful when typedeffing not to use typedeffed literals in inner loops. I know it's considered polite to provide code, but any implementation would have to be in C, so please accept this extremely fake dummy implementation which in no way resembles the way things really work as a poor substitute: typedefs = { FLOATTYPE: None, INTTYPE: None, LISTTYPE: None, DICTTYPE: None, ... } while True line = lines.next() type, module, adaptor = parsetypedef(line) if type is None: break if typedefs[type] is not None: raise SyntaxError("Typedef redef") typedefs[type] = adaptor if module is not None: emit_bytecode_for_import_from(type, module, adaptor) else: emit_bytecode_for_assignment(type, adaptor) parse([line] + lines) ... def emit_float(...): if typedefs[FLOATTYPE] is not None: emit_constant(typedefs[FLOATTYPE][0], stringliteral) else: ... # standard behaviour def emit_list(...): if typedefs[LISTTYPE] is not None: emit(LOADGLOBAL, typedefs[LISTTYPE]) # standard behaviour if typedefs[LISTTYPE] is not None: emit(CALL_FUNCTION) # standard behaviour All rights are assigned to the Python Software Foundation [View Less]

6 8

Re: [Python-ideas] non-Pre-PEP: Syntactic replacement of built-in types with user-defined callables (Take 2... fewer newlines!)
by Raymond Hettinger Jan. 31, 2008

Jan. 31, 2008

> If I understood your proposal correctly, it's just about > dynamically *replacing* the built-in types (with their > respective syntax) with some type of your own. FWIW, there is an interesting type replacement recipe on the bottom of the page at: http://docs.python.org/lib/module-tokenize.html Raymond

1 0

Re: [Python-ideas] non-Pre-PEP: Syntactic replacement of built-in pes with user-defined callables.
by Matt Chisholm Jan. 28, 2008

Jan. 28, 2008

I don't think I followed all of what you wrote. However, it would certainly be convenient shorthand to be able to say that, for an entire file, program, or module, the float literal syntax created Decimals instead. And I can imagine cases where an entire app or module was always using ordered dicts instead of dicts, or frozensets instead of sets. -matt

1 0

non-Pre-PEP: Syntactic replacement of built-in types with user-defined callables.
by Taro Jan. 28, 2008

Jan. 28, 2008

Hi all, Built-in types such as float, string, or list are first-class citizens in Python sourcefiles, having syntactic support: myfloat = 1.0 mystring = "my string" mylist = [1,2,4,8] mydict = {1:"a", 2:"b", 3:"c"} myset = {1,2,3} User-defined classes are second-class citizens, requiring data to be manually converted from a type: mydecimal = Decimal("1.00000000000000001") myrope = Rope("my rope") myblist = BList([1,2,4,8]) myordereddict = … [View More]OrderedDict((1,"a"), (2, "b"), (3, "c")) myfrozenset = frozenset([1,2,3]) If there's only one or two conversions needed in a file, then such conversion is not particularly burdensome, but if one wants to consistently use (say) decimals throughout a file then the ability to use a literal syntax makes for prettier source. Some languages have open types, allowing the addition of methods to built-in types. This is not considered desired behaviour for Python, since modifications made in one module can potentially affect code in other modules. A typedef is syntactic sugar to allow user-defined replacements to be treated as first-class citizens in code. They affect only the module in which they appear and do not modify the original type. To be typedeffable, something must be a builtin type, have a constant/syntactic representation, and be callable. Hence, typedeffable types would be limited to complex, dict, float, int, ?object?, list, slice, set, string, and tuple. No modification is made to __builtins__ or types, so conversion and/or reference to the original type is still possible. The syntax for a typedef is: from MODULE typedef ADAPTOR as TYPE OR typedef BUILTINADAPTOR as TYPE Syntactic constants of a given type are then wrapped with a call: ADAPTOR(SOURCELITERAL) where SOURCELITERAL is the string that appears in the sourcecode eg: from decimal typedef Decimal as float i = 1.000000000000000000000000000001 translates as: from decimal import Decimal as float i = Decimal("1.000000000000000000000000000001") Syntactic collections of a given type are always provided with a list of objects, eg: from decimal typedef Decimal as float from blist typedef BList as list i = 1.000000000000000000000000000001 b = [1.1, 4.2] translates as: from decimal import Decimal as float from blist import BList as list b = Blist([Decimal("1.1"), Decimal("4.2")]) and from collections typedef OrderedDict as dict d = {1:"a", 2:"b", 3:"c"} as: from collections import OrderedDict as dict d = OrderedDict([(1,"a"), (2,"b"), (3,"c")]) A typedef appears at the start of a module immediately after any __future__ imports. As no adaptors can be defined in a module before a typedef and typedefs are in no way a forward declaration, "typedef ADAPTOR as TYPE" only works for builtins, since to do otherwise would lead to one of two unpalatable options; either: a/ definition of adaptors would have to be allowed pre-typedef, which would allow them to be buried in code, making them far easier to miss; or b/ adaptors would be defined after the typedef, which means that you'd have to handle: typedef float as float def float(): pass or: typedef MyObject as object class MyObject(object): pass or: typedef myfloat as float x = 1.1 def myfloat(): pass It is true that if a valid typedef is made, the type can be redefined within the module; but the "consenting adults" rule applies -- it's possible to redefine str and float multiple times within a module as well, but that isn't recommended either (and the typedef at the top of the module at least indicates that non-standard behaviour is to be expected) It is a SyntaxError to typedef the same type more than once: from decimal typedef Decimal as float from types typedef FloatType as float #SyntaxError("Type 'float' already redefined.") Spelling: "typedef" is prettier than "pragma", and less likely to be in use than "use" but its behaviour is somewhat different from C's typedef, so perhaps another term may be preferred. Theoretical Performance Differences: Since a typedef is purely syntactic sugar, and all tranformational work would be done at compilation, running code should be no slower (there should be no new opcodes necessary) and by default no faster that performing manual conversion (though they may assist an optimisation). Unless optimisation magic is available, performance-critical code should be careful when typedeffing not to use typedeffed literals in inner loops. I know it's considered polite to provide code, but any implementation would have to be in C, so please accept this extremely fake dummy implementation which in no way resembles the way things really work as a poor substitute: typedefs = { FLOATTYPE: None, INTTYPE: None, LISTTYPE: None, DICTTYPE: None, ... } while True line = lines.next() type, module, adaptor = parsetypedef(line) if type is None: break if typedefs[type] is not None: raise SyntaxError("Typedef redef") typedefs[type] = adaptor if module is not None: emit_bytecode_for_import_from(type, module, adaptor) else: emit_bytecode_for_assignment(type, adaptor) parse([line] + lines) ... def emit_float(...): if typedefs[FLOATTYPE] is not None: emit_constant(typedefs[FLOATTYPE][0], stringliteral) else: ... # standard behaviour def emit_list(...): if typedefs[LISTTYPE] is not None: emit(LOADGLOBAL, typedefs[LISTTYPE]) # standard behaviour if typedefs[LISTTYPE] is not None: emit(CALL_FUNCTION) # standard behaviour All rights are assigned to the Python Software Foundation [View Less]

1 0

More on set literals
by VanL Jan. 26, 2008

Jan. 26, 2008

I like Raymond's suggestion (apparently adopted) that {1,2,3} is a frozenset literal. However, I also like the {{1,2,3}} syntax. So I would propose that {{}} become the literal for the *mutable* set, not the frozenset. So: frozenset() # empty frozenset {1,2,3} # frozenset literal {} # empty dict {1:2, 3:4} #dict literal {{}} (or set()) # empty mutable set {{1,2,3}} # set literal My rationale is as follows: 1. It visually distinguishes sets and frozensets, without making them take up a … [View More]

5 4

A number is a number
by Neil Toronto Jan. 26, 2008

Jan. 26, 2008

Isn't it? Python 3.0 integers are just integers. Now ceil and floor return ints from float arguments. It seems like things are moving closer to just having a single "number" type. For most applications, because of duck typing, you'd never know or care whether you're punting a float, int, or complex number around, and you'd usually not care. Why not just go whole-hog and unify them all? Neil

2 1

Re: [Python-ideas] An easier syntax for writing decorators(&similar things)?
by Steven Bethard Jan. 25, 2008

Jan. 25, 2008

On Jan 24, 2008 3:26 PM, Aaron Brady <castironpi(a)comcast.net> wrote: > > I don't consider that a use case, or real code. ;-) Yes, you can > > construct curry with it. But what do you want to use curry for? Show > > me some actual Python packages that use the curry function (or your > > prepartial function) and then we can talk. > > Original function: > 1. urlparse( urlstring[, default_scheme[, allow_fragments]]) > 2. urlretrieve( url[, … [View More]

2 1

Re: [Python-ideas] An easier syntax for writing decorators (& similar things)?
by Aaron Brady Jan. 24, 2008

Jan. 24, 2008

> -----Original Message----- > On 8 Oct 2007, at 10:57, Arnaud Delobelle wrote: > > > > On Mon, October 8, 2007 4:33 am, Adam Atlas wrote: > >> When writing decorators especially when it's one that needs arguments > >> other than the function to be wrapped, it often gets rather ugly... > [...] > > Whhy not create a (meta-)decorator to do this? Something like: > [...] Following up post from 10/8/07. > To follow up on my untested suggestion, … [View More]

4 16

Re: [Python-ideas] adopt an enum type for the standard library?
by Raymond Hettinger Jan. 24, 2008

Jan. 24, 2008

[Mark Summerfeld] > I think enums are a common enough requirement to be worth >adding to the standard library---not to the language. -1 This is clutter. Also, I disagree about there being a need. We've long been able to roll our own with a simple class definition (like the first example shown below), but people rarely do that. They don't want to pay the cost in speed (for the attribute lookup) and find that all the prefixed references make their code look more Javaesque that … [View More]

3 3

Ellipsis Literal
by Raymond Hettinger Jan. 24, 2008

Jan. 24, 2008

[Raymond Hettinger] >> I missed the conversation on this one. >> Was there a use case or a reason to add this? [Robert Kern] > It was added for Numeric a long time ago. The ellipsis syntax has been around for a while. What is new is the Ellipsis literal in Py3.0. See snippets below. Raymond ------------------------------------ Python 2.6a0 (trunk:59985:59987, Jan 15 2008, 12:54:09) [GCC 4.1.1 (Gentoo 4.1.1)] on linux2 >>> ... File "<stdin>", line 1 ... … [View More]

1 0

callback support for storxxxx methods in ftplib?
by Terry Carroll Jan. 21, 2008

Jan. 21, 2008

What's the chance of having support added to the storbinary and storlines to support callback, just like retrbinary and retrlines has, for Python 2.6? There's a patch for this at http://bugs.python.org/issue1221598 but it hasn't seemed to generate much enthusiasm. I've had at least one instance where I've needed this, and monkey-patched in this patch to get the functionality. It's also just plain odd that the file transfer capability is not symmetrical; is there any reason why callback … [View More]

2 1

write to cell
by Aaron Brady Jan. 21, 2008

Jan. 21, 2008

Decorator 'FreeVarArr', free variable array, returns an array of its decoratee (decorated function), with free variables set by name to a range of values. Produced & attached. import new def cell_values( *cells ): return [ cell.cell_contents for cell in cells ] def CellMake( *opts ): dumbopts= [ 'opt%i'% i for i in range( len( opts ) ) ] dumbvars= ', '.join( dumbopts ) innermakefmt= "def innermake( %s ):\n\tdef toget(): %s\n\treturn toget" exec innermakefmt% ( … [View More]

1 0

Empty set {} and empty dict {:} ?
by Mark Summerfield Jan. 17, 2008

Jan. 17, 2008

I just wondered if changing the empty set & dict syntax might be possible. s = {} # empty set d = {:} # empty dict I think this would be more understandable to newcomers since to create single element ones we have: s = {1} d = {1:1} ? -- Mark Summerfield, Qtrac Ltd., www.qtrac.eu

6 5

Default decorator?
by Guido van Rossum Jan. 17, 2008

Jan. 17, 2008

Peter Norvig suggested an idea to me over lunch: a "default decorator". This would be something you could set once per module and it would be invoked for each function definition in the same way as a decorator is invoked, before any explicit decorators. His use case was something that wraps every function that uses argument annotations with something that interprets those annotations in a certain way and enforces that interpretation. It would save having to explicitly annotate every function or … [View More]

11 16

Re: [Python-ideas] Default decorator?
by Christian Heimes Jan. 17, 2008

Jan. 17, 2008

Guido van Rossum wrote: > Those are indeed the main reasons for wanting something built-in > rather than something that scans a module's namespace -- the idea > being that within the scope of the declaration *every* def and lambda > gets passed to this hook first (and the hook can pass on anything that > doesn't have annotations, for example). Ah! Ok ... I got it. It sounds like a job for a new builtin __build_funcion__ which is called for the opcode MAKE_FUNCTION. Christian

1 0

other thread exception
by Aaron Brady Jan. 14, 2008

Jan. 14, 2008

Raise an exception in another thread.

1 0

sharedmutable locking solution
by Aaron Brady Jan. 13, 2008

Jan. 13, 2008

Practical concurrency solution attached and produced below. Includes worked example. Brainstorm attached for referencing. Excerpt: 1. Put a single thread in charge 2. Lock mutation and/or all operations 3. @mutation decorator 4. List-only solution 5. @onfulfill decorator 6. Ideal solution (implemented) Timing: Important Unimportant Return value: Ignore (i.) (ii.) Use (i.) (iii.) sharedmutable.py --- from __future__ import … [View More]with_statement import threading import thread from Queue import Queue class Ref: '''To adjust a value a reference to which is not available.''' def __init__( self, val= None ): self.val= val def __repr__( self ): return repr( self.val ) class LockerItem( object ): def __call__( self, farevent ): raise NotImplemented class LockerItemBlock( LockerItem ): '''Turn-taking Locker item. Call frees its event, frees and waits on its parameter (must have 'clear' and 'wait' methods. Use 'wait' to block for Call to set event, and block calling event.''' def __init__( self ): self.event= threading.Event() def __call__( self, farevent ): farevent.clear() self.event.set() def wait( self, timeout= None ): self.event.wait( timeout ) class LockerItemFaF( LockerItem ): '''Fire-and-Forget Locker item; calling just calls func. Use to polymorphisize LockerItemBlock.''' def __init__( self, func, *ar, **kwar ): self.func, self.ar, self.kwar= func, ar, kwar self.ret= None def __call__( self, _ ): self.ret= self.func( *self.ar, **self.kwar ) class Locker( object ): '''Synchronization class. Operations can honor: i. Fire, block for completion (timing important: do here.) ii. Fire, launch new thread with result upon completion (timing unimportant, return important: do something with result later, in turn.) iii. Fire, forget, continue (timing & return ignored: just do.) Timing: Important Unimportant Return value: Ignore (i.) (ii.) Use (i.) (iii.) Corresponding instance functions are: i. Locker.op( operation & args ) -or- Locker.acq() ...code block... Locker.rel() -or- with Locker: ...code block... ii. Decorator or otherwise: Locker.onfulfill( operation & args ) ( oncompletioncallable ) iii. Fire-and-forget (faf) + options: Locker.faf( operation & args ) To accomplish this, a Locker instance has a Queue of callables, and -produces- LockerItemFaF (fire-and-forget) and LockerItemBlock instances, which are enqueued and granted in order received. acq() and op() "get the caller in line" for ownership; faf() gets something else in line: in particular, a LockerItemFaF instance. A LockerItem subclass instance is called when "it's its turn" in Queue, with 'noget' as the parameter; '_mainth', started in initialization, blocks on 'noget' after each 'get' operation. instance.rel() clears 'noget', and LockerItemFaF.__call__ does not set it. (LockerItemBlock.__call__ does; acq() enqueues LockerItemBlock instances.) Usage: "with 'instance': (suite)" is equivalent to: instance.acq() (suite) instance.rel() (suite) may not call acq(). 'op' can be used for simple-statement suites. instance.op( listA.append, None ) instance.op( listA.reverse ) Decorator 'instance.onfulfill' spawns a new thread, whence, when it's its turn, it calls its decoratee with the result of the operation as the only parameter. @instance.onfulfull( dequeA.popleft ) def onfulfill1( result ): #do something with the popped value print '%s was popped\n'% result, Use @ThreadUtils.ThFork for something complex. @ThreadUtils.ThFork def fork1(): with instance: #something complex print listA ''' def __init__( self ): self.queue= Queue() self.noget= threading.Event() self.thread= th= threading.Thread( target= self._mainth ) th.setDaemon( True ) th.start() def _mainth( self ): self.noget.clear() while 1: item= self.queue.get() item( self.noget ) self.noget.wait() def acq( self ): item= LockerItemBlock() self.queue.put( item ) item.wait() return item def rel( self ): self.noget.set() def op( self, func, *ar, **kwar ): self.acq() ret= func( *ar, **kwar ) self.rel() return ret def __enter__( self ): return self.acq() def __exit__( self, *excs ): self.rel() def onfulfill( self, func, *ar, **kwar ): '''decorator launches the decoratee in separate thread upon completion of func.''' locfunc= Ref() def callee(): result= self.op( func, *ar, **kwar ) locfunc.val( result ) def prefulfill( func ): locfunc.val= func th= threading.Thread( target= callee ) th.start() return prefulfill def faf( self, func, *ar, **kwar ): '''fire and forget''' return self.fafroot( False, None, func, *ar, **kwar ) def fafoption( self, func, *ar, **kwar ): return self.fafroot( True, None, func, *ar, **kwar ) def faftimeout( self, timeout, func, *ar, **kwar ): return self.fafroot( False, timeout, func, *ar, **kwar ) def fafroot( self, block, timeout, func, *ar, **kwar ): item= LockerItemFaF( func, *ar, **kwar ) self.queue.put( item, block, timeout ) return item if __name__== '__main__': '''Thing to notice: fulfill1 prints a >0 value when thTry producers are adding integers in the closed interval [300,600]. By design there is a small chance of assertion failure, unobserved yet.''' import time import random counter= 0 def simplecounter(): global counter ret= counter counter+= 1 time.sleep( random.uniform( 0, 0.01 ) ) return counter listA= [] lockerA= Locker() def thTry(): while 1: with lockerA: ret= simplecounter() listA.append( ret ) print ret, '''this assertion fails outside of locker with.''' assert all( [ listA[i]< listA[i+1] for i in range( len( listA )- 1 ) ] ) if random.random()< 0.8 or len( listA )> 10: '''fire-and-forget example. 80% chance of removing an element (hence may fail), and 100% if listA has 'a lot' of elements.''' lockerA.faf( listA.pop, 0 ) '''return is important on this one; must block for.''' ret= list( lockerA.op( reversed, listA ) ) if len( ret )> 1: assert all( [ ret[i]> ret[i+1] for i in range( len( ret )- 1 ) ] ) if random.random()< .05: '''return is important, but timing is not.''' @lockerA.onfulfill( set, listA ) def fulfill1( result ): count= 0 for si in result: if 300<= si<= 600: count+= 1 print "\n\t%i counts in [300,600]\n"% count, def thInterfere(): while 1: with lockerA: '''remove a multiple of 2 from somewhere.''' ret= None for i in range( len( listA ) ): if listA[ i ]% 2== 0: ret= listA.pop( i ) break if ret is not None: assert ret% 2== 0 print '\n\tremoved %i\n'% ret, time.sleep( 0.5 ) def thMon(): while 1: print '\n\t%s\n'% listA, time.sleep( 0.5 ) thread.start_new_thread( thMon, () ) thread.start_new_thread( thInterfere, () ) for _ in range( 10 ): '''start a bunch of producer threads.''' thread.start_new_thread( thTry, () ) time.sleep( 0.1 ) '''and wait.''' time.sleep( 1000 ) [View Less]

1 0

generic Ref class
by Aaron Brady Jan. 12, 2008

Jan. 12, 2008

For iteration and pass-by-reference semantics: class Ref: def __init__( self, val): self.val= val To modify list during iteration: def refs( iterable ): return [ Ref( x ) for x in iterable ] Then: for x in refs( listA ): x.val+= 1 Better than: for i, x in enumerate( listA ): listA[i]= x+ 1 Example is naturally trivial; imagine. No bloat here; get over it.

3 5

Re: [Python-ideas] generic Ref class
by Aaron Brady Jan. 12, 2008

Jan. 12, 2008

> -----Original Message----- > From: Aaron Brady [mailto:castironpi@comcast.net] > Sent: Saturday, January 12, 2008 2:26 PM > To: 'python-ideas(a)python.org' > Subject: RE: [Python-ideas] generic Ref class > > > -----Original Message----- > > From: python-ideas-bounces(a)python.org [mailto:python-ideas- > > bounces(a)python.org] On Behalf Of Aaron Brady > > > > > -----Original Message----- > > > From: python-ideas-bounces+castironpi=… [View More]

1 0

o(n**2) problem with marshal.dumps for large objects, with patch
by Aaron Watters Jan. 11, 2008

Jan. 11, 2008

Hi folks. Much to my surprise I found that one of my applications seemed to be running slow as a result of marshal.dumps. I think the culprit is the w_more(...) function, which grows the marshal buffer in 1k units. This means that a marshal of size 100k will have 100 reallocations and string copies. Other parts of Python (and java etc) have a proportional reallocation strategy which reallocates a new size based on the existing size. This mean a 100k marshal requires just 5 or so … [View More]

3 2

Thread object
by Aaron Brady Jan. 11, 2008

Jan. 11, 2008

Hey Group: I find myself using Threads quite a bit, and I so often write: bContinue= True And in the thread: while bContinue: And elsewhere: if ...: bContinue= False Proposing for the standard library: th= threading.Thread( target= myfunction ) def myfunction( selfth ): while selfth.bContinue: ... and th.bContinue= False. Of course, there is a little more functionality that's very common as well. Throw it in, touched up from above: def pausesleep( self, secs ): '''Pauses … [View More]

1 0

Thread object
by Aaron Brady Jan. 11, 2008

Jan. 11, 2008

Hey Group: I find myself using Threads quite a bit, and I so often write: bContinue= True And in the thread: while bContinue: And elsewhere: if ...: bContinue= False Proposing for the standard library: th= threading.Thread( target= myfunction ) def myfunction( selfth ): while selfth.bContinue: ... and th.bContinue= False. Of course, there is a little more functionality that's very common as well. Throw it in, touched up from above: def pausesleep( self, secs ): '''Pauses … [View More]

1 0

Batty idea of the week: no implementation inheritance
by Neil Toronto Jan. 10, 2008

Jan. 10, 2008

It occurred to me that every problem I've had with object-oriented programming stems from the fact that subclasses implicitly inherit implementation details from their parent classes. It also occurred to me that I've never solved a problem with implementation inheritance that couldn't be done via composition and delegation approximately as easily. This kind of delegation would be similar to subclassing: class A: def foo(self): # do something cool class B: … [View More]# Not a subclass of A, but acts like one def __init__(self): self.a = A() def foo(self): # do something before ret = self.a.foo() # do something after return ret # or foo = A.foo for simple cases? For lack of a better term (I'm probably just not well-versed enough in language theory) I'll call it reverse delegation. The big UI difference between this and subclassing is that here A retains control over its implementation and its writer doesn't have to worry about whether changing anything will break subclasses - because there aren't any. There's also forward delegation for when a class doesn't want to care about how something is implemented: class A: def __init__(self, barimpl): self.barimpl = barimpl # or gets it by some other means def bar(self): return self.barimpl.bar() class B: def bar(self): # do something cool For some reason this gets called "dependency injection". (I know why, but IMO it's a horrible name.) It's typical OO practice to solve the same problem by defining A.bar as abstract, though it's increasingly frowned upon in favor of forward delegation / dependency injection. It occurred to me that this sort of thing would work perfectly with duck typing, and even duck typing plus something like Java's interfaces. In the first example, as long as A and B have the same interface they could each pass the same type checks. In the second, A could define an interface containing bar (or more) and accept anything implementing it. The big downside to both delegation types is that they're wordy, especially with interfaces added. With the right syntactic support (I admit I haven't given this much thought) it might be as nice as implementation inheritance. I also have a niggling feeling that I'm missing something, especially with regards to multiple inheritance, though I've never understood what the big deal was with that past inheriting an interface or convenient mixins. Neil [View Less]

1 0