[Python-Dev] Caching objects in memory
Is there a document that details which objects are cached in memory (to not create the same object multiple times, for performance)? If not, could please somebody point me out where this is implemented for strings? Thank you! .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Caching objects in memory
Facundo Batista <[EMAIL PROTECTED]> writes: > Is there a document that details which objects are cached in memory > (to not create the same object multiple times, for performance)? No. > If not, could please somebody point me out where this is implemented > for strings? In PyString_FromStringAndSize and PyString_FromString, it seems to me. Cheers, mwh -- I also feel it essential to note, [...], that Description Logics, non-Monotonic Logics, Default Logics and Circumscription Logics can all collectively go suck a cow. Thank you. -- http://advogato.org/person/Johnath/diary.html?start=4 ___ 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: Caching objects in memory
Facundo Batista wrote: Is there a document that details which objects are cached in memory (to not create the same object multiple times, for performance)? why do you think you need to know? If not, could please somebody point me out where this is implemented for strings? Objects/stringobject.c (where else? ;-) ___ 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] PEP 310 and exceptions
holger krekel wrote: Moreover, i think that there are more than the "transactional" use cases mentioned in the PEP. For example, a handler may want to log exceptions to some tracing utility or it may want to swallow certain exceptions when its block does IO operations that are ok to fail. With the current PEP 310 definition, these can be manually handled using sys.exc_info() in the __exit__ method. Cleaning up my earlier transaction handler example: class transaction(object): def __enter__(self): begin_transaction() def __exit__(self): ex = sys.exc_info() if ex[0] is not None: abort_transaction() else: commit_transaction() Alternately, PEP 310 could be defined as equivalent to: if hasattr(x, '__enter__'): x.__enter__() try: try: ... except: if hasattr(x, '__except__'): x.__except__(*sys.exc_info()) else: raise finally: x.__exit__() Then the transaction handler would look like: class transaction(object): def __enter__(self): self.aborted = False begin_transaction() def __except__(self, *exc_info): self.aborted = True abort_transaction() def __exit__(self): if not self.aborted: commit_transaction() Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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] PEP 310 and exceptions
[EMAIL PROTECTED] (holger krekel) wrote: > basically translates to: > > if hasattr(x, '__enter__'): > x.__enter__() > try: > ... > except: > if hasattr(x, '__except__'): x.__except__(...) > else: x.__exit__() > else: > x.__exit__() Nope... >>> def foo(): ... try: ... print 1 ... return ... except: ... print 2 ... else: ... print 3 ... >>> foo() 1 >>> - Josiah ___ 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] PEP 310 and exceptions
Hi all, probably unsuprisingly i am still pondering the idea of having an optional __except__ hook on block handlers. The PEP says this about this: An extension to the protocol to include an optional __except__ handler, which is called when an exception is raised, and which can handle or re-raise the exception, has been suggested. It is not at all clear that the semantics of this extension can be made precise and understandable. For example, should the equivalent code be try ... except ... else if an exception handler is defined, and try ... finally if not? How can this be determined at compile time, in general? In fact, i think the translation even to python code is not that tricky: x = X(): ... basically translates to: if hasattr(x, '__enter__'): x.__enter__() try: ... except: if hasattr(x, '__except__'): x.__except__(...) else: x.__exit__() else: x.__exit__() this is the original definition from the PEP with the added except clause. Handlers are free to call 'self.__exit__()' from the except clause. I don't think that anything needs to be determined at compile time. (the above can probably be optimized at the bytecode level but that is a side issue). Moreover, i think that there are more than the "transactional" use cases mentioned in the PEP. For example, a handler may want to log exceptions to some tracing utility or it may want to swallow certain exceptions when its block does IO operations that are ok to fail. cheers, holger ___ 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] PEP 310 and exceptions
On Apr 22, 2005, at 16:51, holger krekel wrote: Moreover, i think that there are more than the "transactional" use cases mentioned in the PEP. For example, a handler may want to log exceptions to some tracing utility or it may want to swallow certain exceptions when its block does IO operations that are ok to fail. I entirely agree! In fact, I was discussing this very issue recently with colleagues at Google, most of them well acquainted with Python but not all of them Python enthusiasts, and I was surprised to see unanimity on how PEP 310 *with* __except__ would be a huge step up in usefulness wrt the simple __enter__/__exit__ model, which is roughly equivalent in power to the C++ approach (destructors of auto variables) whose absence from Python and Java some people were bemoaning (which is how the whole discussion got started...). The use cases appear to be aleph-0 or more...;-). Essentially, think of it of encapsulating into reusable forms many common patterns of try/except use, much like iterators/generators can encapsulate looping and recursive constructs, and a new vista of uses open up... Imagine that in two or three places in your code you see something like... try: ...different blocks here... except FooError, foo: # some FooError cases need whizbang resetting before they propagate if foo.wobble > FOOBAR_RESET_THRESHOLD: whizbang.reset_all() raise With PEP 310 and __except__, this would become: with foohandler: ...whatever block.. in each and every otherwise-duplicated-logic case... now THAT is progress!!! IOW, +1 ... ! Alex ___ 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] a few SF bugs which can (probably) be closed
Good morning/evening/: Here a few sourceforge bugs which can probably be closed: [ 1168983 ] : ftplib.py string index out of range Original poster reports that the problem disappeared after a patch committed by Raymond [ 1178863 ] Variable.__init__ uses self.set(), blocking specialization seems like a dup of 1178872 [ 415492 ] Compiler generates relative filenames seems to have been fixed at some point. I could not reproduce it with python2.4 [ 751612 ] smtplib crashes Windows Kernal. Seems like an obvious Windows bug (not python's bug) and seems to be unreproducible Ilya ___ 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] Proper place to put extra args for building
Martin v. LÃwis wrote: > Brett C. wrote: > >>Yep, you're right. I initially thought that the parentheses meant it was a >>Makefile-only variable, but it actually goes to the environment for those >>unknown values. >> >>Before I check it in, though, should setup.py be tweaked to use it as well? I >>say yes. > > > You means sysconfig.py, right? No, I mean Python's setup.py; line 174. > Probably yes. > You mean Distutils' sysconfig, right? I can change that as well if you want. -Brett ___ 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] Proper place to put extra args for building
Brett C. wrote: > Yep, you're right. I initially thought that the parentheses meant it was a > Makefile-only variable, but it actually goes to the environment for those > unknown values. > > Before I check it in, though, should setup.py be tweaked to use it as well? I > say yes. You means sysconfig.py, right? Probably yes. This is a mess. distutils should just do what Makefile does for builtin modules, i.e. use CFLAGS from the Makefile. Instead, it supports CFLAGS as being additive to the Makefile value CFLAGS, which in turn it just *knows* $(BASECFLAGS) $(OPT). Regards, Martin ___ 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] anonymous blocks
Skip Montanaro wrote: Guido> or perhaps even (making "for VAR" optional in the for-loop syntax) Guido> with Guido> in synchronized(the_lock): Guido> BODY This could be a new statement, so the problematic issue of implicit try/finally in every for statement wouldn't be necessary. That complication would only be needed for the above form. s/in/with/ to get PEP 310. A parallel which has been bugging me is the existence of the iterator protocol (__iter__, next()) which you can implement manually if you want, and the existence of generators, which provide a nice clean way of writing iterators as functions. I'm wondering if something similar can't be found for the __enter__/__exit__ resource protocol. Guido's recent screed crystallised the idea of writing resources as two-part generators: def my_resource(): print "Hi!" # Do entrance code yield None# Go on with the contents of the 'with' block print "Bye!" # Do exit code Giving the internal generator object an enter method that calls self.next() (expecting None to be returned), and an exit method that does the same (but expects StopIteration to be raised) should suffice to make this possible with a PEP 310 style syntax. Interestingly, with this approach, "for dummy in my_resource()" would still wrap the block of code in the entrance/exit code (because my_resource *is* a generator), but it wouldn't get the try/finally semantics. An alternative would be to replace the 'yield None' with a 'break' or 'continue', and create an object which supports the resource protocol and NOT the iterator protocol. Something like: def my_resource(): print "Hi!" # Do entrance code continue # Go on with the contents of the 'with' block print "Bye!" # Do exit code (This is currently a SyntaxError, so it isn't ambiguous in any way) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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: switch statement
Michael Chermside wrote: > Now the pattern matching is more interesting, but again, I'd need to > see a proposed syntax for Python before I could begin to consider it. > If I understand it properly, pattern matching in Haskell relies > primarily on Haskell's excellent typing system, which is absent in > Python. Why not just use classes? With either mixins or new-style classes, it is quite reasonable to use many small classes for fine distinctions. Change if predicate1(obj): action1(obj) elif predicate2(obj): action2(obj) ... else: default(obj) into either try: obj.action(locals()) except AttributeError: default(obj, locals()) or if hasattr(obj, "action"): obj.action(locals()) else: And then define an action method (perhaps through inheritance from a mixin) for any object that should not take the default path. The object's own methods will have access to any variables used in the match and locals will have access to the current scope. If you have at least one class per "switch", you have a switch statement. The down sides are that (1) Your domain objects will have to conform to a least a weak OO model (or take the default path) (2) Logic that should be together will be split up. Either classes will be modified externally, or the "switch statement" logic will be broken up between different classes. If single-method mixins are used to keep the logic close, then real objects will have to pick an ancestor for what may seem like arbitrary reasons. These objections apply to any matching system based on types; the difference is that other languages have often already paid the price. For Python it is an incremental cost incurred by the match system. -jJ ___ 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] defmacro (was: Anonymous blocks)
As best I can tell, the anonymous blocks are used to take
care of boilerplate code without changing the scope -- exactly
what macros are used for. The only difference I see is that in
this case, the macros are limited to entire (possibly compound)
statements.
To make this more concrete,
Guido:
>> in synchronized(the_lock):
>> BODY
Nick Coghlan:
> s/in/with/ to get PEP 310.
...
>Guido's recent screed crystallised the idea of writing resources
> as two-part generators:
...
[Adding Reinhold Birkenfeld's suggestion of a blank yield]
> def my_resource():
>print "Hi!" # Do entrance code
>yield # Go on with the contents of the 'with' block
>print "Bye!"# Do exit code
The macro itself looks reasonable -- so long as there is only
ever one changing block inside the macro. I'm not sure that
is a reasonable restriction, but the alternative is ugly enough
that maybe passing around locals() starts to be just as good.
What about a block that indicates the enclosed namespaces
will collapse a level?
defmacro myresource(filename):
with myresource("thefile"):
def reader():
...
def writer():
...
def fn():
Then myresource, reader, writer, and fn would share a
namespace without having to manually pass it around.
-jJ
___
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] PEP 310 and exceptions
Nick Coghlan wrote: Alternately, PEP 310 could be defined as equivalent to: if hasattr(x, '__enter__'): x.__enter__() try: try: ... except: if hasattr(x, '__except__'): x.__except__(*sys.exc_info()) else: raise finally: x.__exit__() In light of Alex's comments, I'd actually like to suggest the below as a potential new definition for PEP 310 (making __exit__ optional, and adding an __else__ handler): if hasattr(x, '__enter__'): x.__enter__() try: try: # Contents of 'with' block except: if hasattr(x, '__except__'): if not x.__except__(*sys.exc_info()): # [1] raise else: raise else: if hasattr(x, '__else__'): x.__else__() finally: if hasattr(x, '__exit__'): x.__exit__() [1] A possible tweak to this line would be to have it swallow the exception by default (by removing the conditional reraise). I'd prefer to make the silencing of the exception explicit, by returning 'True' from the exception handling, and have 'falling off the end' of the exception handler cause the exception to propagate. Whichever way that point goes, this definition would allow PEP 310 to handle Alex's example of factoring out standardised exception handling, as well as the original use case of resource cleanup, and the transaction handling: class transaction(object): def __enter__(self): begin_transaction() def __except__(self, *exc_info): abort_transaction() def __else__(self): commit_transaction() Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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
