Re: [Python-Dev] math.areclose ...?
Please, I don't much care about the fine points of the function's semantics, but PLEASE rename that function to are_close. Every time I see this subject in my email client I have to think for a few seconds what the hell 'areclose' means. This time it's not just because of the new PEP 8, 'areclose' is really really hard to read. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] Python modules should link to libpython
gjc:/usr/lib/python2.4/lib-dynload$ ldd itertools.so libpthread.so.0 => /lib/libpthread.so.0 (0x2abcc000) libc.so.6 => /lib/libc.so.6 (0x2ace2000) /lib/ld-linux-x86-64.so.2 (0x4000) gjc:/usr/lib/python2.4/lib-dynload$ It seems that Python C extension modules are not linking explicitly to libpython. Yet, they explicitly reference symbols defined in libpython. When libpython is loaded in a global scope all is fine. However, when libpython is dlopen()ed with the RTLD_LOCAL flag, python C extensions always get undefined symbols. This problem happened recently with the nautilus-python package, which installs an extension for the Nautilus file manager that allows extensions in Python. For performance reasons, it now opens extensions with RTLD_LOCAL flag, thus breaking python extensions. Any thoughts? Should I go ahead and open a bug report (maybe with patch), or is this controversial? -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Octal literals
On Tue, 2006-01-31 at 17:17 -0500, Andrew Koenig wrote: > > Apart from making 0640 a syntax error (which I think is wrong too), > > could this be solved by *requiring* the argument to be a string? (Or > > some other data type, but that's probably overkill.) > > That solves the problem only in that particular context. > > I would think that if it is deemed undesirable for a leading 0 to imply > octal, then it would be best to decide on a different syntax for octal > literals and use that syntax consistently everywhere. +1, and then issue a warning every time the parser sees leading 0 octal constant instead of the new syntax, although the old syntax would continue to work for compatibility reasons. > > I am personally partial to allowing an optional radix (in decimal) followed > by the letter r at the beginning of a literal, so 19, 8r23, and 16r13 would > all represent the same value. For me, adding the radix to the right instead of left looks nicer: 23r8, 13r16, etc., since a radix is almost like a unit, and units are always to the right. Plus, we already use suffix characters to the right, like 10L. And I seem to recall an old assembler (a z80 assembler, IIRC :P) that used a syntax like 10h and 11b for hex an bin radix. Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the casual observer; perhaps a suffix letter is more readable, since we don't need arbitrary radix support anyway. /me thinks of some examples: 644o # I _think_ the small 'o' cannot be easily confused with 0 or O, but.. 10h # hex.. hm.. but we already have 0x10 101b # binary Another possility is to extend the 0x syntax to non-hex, 0xff # hex 0o644 # octal 0b1101 # binary I'm unsure which one I like better. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] The path module PEP
On Thu, 2006-01-26 at 16:17 +0100, Fredrik Lundh wrote:
> Gustavo J. A. M. Carneiro wrote:
>
> > > If a URI class implemented the same methods, it would be something of a
> > > question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz'
> > > (and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does).
> > > I assume it would be be the latter, and urljoin would be a different
> > > method, maybe something novel like "urljoin".
> >
> > I honestly don't understand the usefulness of join('/foo/bar', 'baz')
> > ever returning '/foo/baz' instead of '/foo/bar/baz'. How would the
> > former be of any use?
>
> it's how URL:s are joined, as noted in the paragraph you replied to
>
> (a "baz" link on the page "/foo/bar" refers to "/foo/baz", not "/foo/bar/baz")
That's not how I see it. A web browser, in order to resolve the link
'baz' in the page '/foo/bar', should do:
join(basename('/foo/bar'), 'baz')
== join('/foo', 'baz')
== '/foo/baz'.
Regards.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
___
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] The path module PEP
On Wed, 2006-01-25 at 22:35 -0600, Ian Bicking wrote:
> Gustavo J. A. M. Carneiro wrote:
> > On a slightly different subject, regarding path / path, I think it
> > feels much more natural path + path. Path.join is really just a string
> > concatenation, except that it adds a path separator in the middle if
> > necessary, if I'm not mistaken.
>
> No, it isn't, which maybe is why / is bad. os.path.join(a, b) basically
> returns the path as though b is interpreted to be relative to a. I.e.,
> os.path.join('/foo', '/bar') == '/bar'. Not much like concatenation at
> all.
Really? This is not like the unix command line. At least in
Linux, /foo/bar is the same as /foo//bar and /foo///bar, etc. But I
admit it can be useful in some cases.
> Plus string concatenation is quite useful with paths, e.g., to add
> an extension.
I see your point. Although perhaps adding an extension to a file
should be the exception and not the rule, since adding extensions is
rarely used compared to joining paths? Maybe Path.add_extension() ?
BTW, regarding Path subclassing basestr, there exists "prior art" for
this Path thing in SCons. In SCons, we (users, I'm not a scons dev)
have to constantly deal with Node instances. Most scons functions that
accept Nodes also accept strings, but a Node is not a string. When
calling an os function with Nodes, one has to convert it to string
first, using str(). IMHO, having to decorate Node instances with str()
sometimes is no big deal, really. And, given enough time, perhaps most
of the python standard library could be enhanced to accept Path
instances in addition to C strings.
> If a URI class implemented the same methods, it would be something of a
> question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz'
> (and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does).
> I assume it would be be the latter, and urljoin would be a different
> method, maybe something novel like "urljoin".
I honestly don't understand the usefulness of join('/foo/bar', 'baz')
ever returning '/foo/baz' instead of '/foo/bar/baz'. How would the
former be of any use? If it has no use, then please don't complicate
things even more :)
Regards.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
___
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] The path module PEP
On Wed, 2006-01-25 at 21:37 +0100, BJörn Lindqvist wrote: > Renaming methods because of PEP 8 (Gustavo, Ian, Jason) > > I'm personally not keen on that. I like most of the names as they > are. abspath(), joinpath(), realpath() and splitall() looks so much > better than abs_path(), join_path(), real_path() and split_all() in my > eyes. If someone like the underscores I'll add it to Open Issues. Function Names Function names should be lowercase, with words separated by underscores as necessary to improve readability. mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility. Method Names and Instance Variables Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability. It is very clear. Whether you agree with PEP 8 or not is not relevant to this discussion. Since this is a completely new module, it should be correctly named from the start. The "familiarity with os.path argument" is a very weak one, IMHO. Plus, the names are full of redundancy. Why abspath(), joinpath(), realpath(), splitall()? Why not instead: absolute(), join(), real(), split() ? Remember that they are all methods of a Path class, you don't need to keep repeating 'path' all over the place[1]. On a slightly different subject, regarding path / path, I think it feels much more natural path + path. Path.join is really just a string concatenation, except that it adds a path separator in the middle if necessary, if I'm not mistaken. Best regards. [1] Yes, I'm the kind of guy who hates struct timeval having tv_sec and tv_usec field members instead of sec and usec. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] The path module PEP
On Tue, 2006-01-24 at 21:22 +0100, BJörn Lindqvist wrote: [...] > # Operations on path strings. > def abspath(sef): ... > def normcase(self): ... > def normpath(self): ... > def realpath(self): ... > def expanduser(self): ... > def expandvars(self): ... > def dirname(self): ... > def basename(self): ... > def expand(self): ... > def splitpath(self): ... > def splitdrive(self): ... > def splitext(self): ... > def stripext(self): ... > def splitunc(self): ... [1] > def joinpath(self, *args): ... > def splitall(self): ... > def relpath(self): ... > def relpathto(self, dest): ... [...etc...] If we wanted to take PEP 8 seriously, those method names should be changed to words_separated_by_underscores. And BTW, what does splitunc do? It really should have a more descriptive name. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] PEP 8 updates/clarifications
Seg, 2005-12-12 às 22:38 -0600, [EMAIL PROTECTED] escreveu: > Jim> I don't understand this argument. Any mutating method or property > Jim> invoked by foreign code changes an object's state. > > Sure, but the only place I need to look for direct changes to the object's > state are in the object's own code. > > Jim> If you provide a property or a pair if accessors that just sets and > Jim> gets an attribute with a slightly different name, that affords no > Jim> more protection than if people were setting the attribute directly. > > Sure it does. Suppose I get an exception in my code because some bit of > code somewhere broke my assumptions about the values an attribute could > assume. If that attribute is only set by the object's own code, I can more > easily debug it (stick in a print or an assert in the places where the > attribute changes, etc). If some external bit of code does something like > > self.foo = Foo() > ... > self.foo.attr = None > > then later in Foo's code I have something like > > self.attr.callme() > > The first thing I need to do is figure out who stomped on self.attr. I have never done this, but in theory you could replace attr with a property whose getter uses sys._getframe() to log each modification of the attribute, thus easily find out who did "self.foo.attr = None". Almost like gdb's 'watch' command. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ 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] PEP 8 updates/clarifications
Dom, 2005-12-11 às 16:30 -0600, Ian Bicking escreveu: > Jim Fulton wrote: > >> Designing for inheritance > >> > >>Always decide whether a class's methods and instance variables > >>should be public or non-public. In general, never make data > >>variables public unless you're implementing essentially a > >>record. It's almost always preferrable to give a functional > > > > >interface to your class instead (and some Python 2.2 > > >developments will make this much nicer). > > > > > > Yes, Python 2.2 developments have made this better. Use of property() > > > should be suggested. > > > > This seems outdated. My impression, in part from time spent > > working with the Python Labs guys, is that it is fine to have public > > data sttributes even for non-"record" types. In fact, I would argue that > > any time you would be tempted to provide "getFoo()" and "setFoo(v)" > > for some "private attribute _foo", it would be better to make it > > public. I certainly find "blah.foo" and "blah.foo = v" to be much > > better than "blah.getFoo()" and blah.setFoo(v)". > > > > Certainly, properties provide a safety belt. I would argue it this > > way: Python APIs can include attributes as well as methods. > > Exposure of an attribute need not constrain the implementation, thanks > > to properties. OTOH, I wouldn't bother with a property unless it's needed. > > So, getting back to the original paragraph, perhaps it could say: > > Decide whether a class's methods and instance variables should be public > or non-public. Non-public methods and variables should start with an > underscore. > > Do not use accessor methods, like ``obj.getFoo()`` and > ``obj.setFoo(v)``, instead just expose a public attribute (``obj.foo``). > If necessary you can use ``property`` to implement the same > functionality that accessor methods would give you. If you do use > properties, getting that property should never have a side effect. > [well... I think that certain side effects like caching and logging are > okay, but I'm not sure how to make that distinction] IMHO, if getting a property involves a potentially long computation, it's better to have an accessor method rather than a property; xpto.getFoobar() hints right away the programmer that to access that value some code has to be run, so the programmer is more likely to store the result in a temp variable for use in the same context, instead of calling it multiple times. Similar reasoning applites for setter vs property =. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ 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] Weak references: dereference notification
Qui, 2005-11-10 às 13:57 +1300, Greg Ewing escreveu: > Gustavo J. A. M. Carneiro wrote: > > > OK, but what if it is a subclass of a builtin type, with instance > > variables? What if the PyObject is GC'ed but the ObjC object remains > > alive, and later you get a new reference to it? Do you create a new > > PyObject wrapper for it? What happened to the instance variables? > > Your proposed scheme appears to involve destroying and > then re-initialising the Python wrapper. Isn't that > going to wipe out any instance variables it may > have had? The object isn't really destroyed. Simply ob_refcnt drops to zero, then tp_dealloc is called, which is supposed to destroy it. But since I wrote tp_dealloc, I choose not to destroy it, and revive it by calling PyObject_Init(), which makes ob_refcnt == 1 again, among other things. > > Also, it seems to me that as soon as the refcount on > the wrapper drops to zero, any weak references to it > will be broken. Or does your resurrection code > intervene before that happens? Yes, I intervene before that happens. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Weak references: dereference notification
Qui, 2005-11-10 às 08:15 +0100, "Martin v. Löwis" escreveu: > Gustavo J. A. M. Carneiro wrote: > > OK, but what if it is a subclass of a builtin type, with instance > > variables? What if the PyObject is GC'ed but the ObjC object remains > > alive, and later you get a new reference to it? Do you create a new > > PyObject wrapper for it? What happened to the instance variables? > > Normally, wrappers don't have state. But if you do have state, this > is how it could work: > > 1. Make two Python objects, PyState and PyWrapper (actually, > PyState doesn't need to be a Python object) > PyState holds the instance variables, and PyWrapper just > holds a pointer to a GObject. > 2. When a Python reference to a GObject is created for the > first time, create both a PyState and a PyWrapper. Have > the GObject point to the PyState, and the PyWrapper to > the GObject. Have the PyState weakly reference the > PyWrapper. > 3. When the refcount to the PyWrapper drops to zero, discard it. > 4. When somebody asks for the data in the PyWrapper, > go to the GObject, then to the PyState, and return the > data from there. > 5. When somebody wants a reference to a GObject which already > has a PyState, check the weak reference to find out > whether there is a PyWrapper already. If yes, return it; > if not, create a new one (and weakly reference it). > 6. When the GObject is discarded, drop the PyState as well. > > This has the following properties: > 1. There are no cyclic references for wrapping GObjects. > 2. Weakly-referencing wrappers is supported; if there > are no strong Python references to the wrapper, > the wrapper goes away, and, potentially, the GObject > as well. > 3. The PyState object lives as long as the GObject. > 4. Using "is" for GObjects/PyWrappers "works": there is > at most one PyWrapper per GObject at any time. > 5. id() of a GObject may change over time, if the wrapper > becomes unreferenced and then recreated. This was my first approach, actually, in patch 4.1 in [1]. Only your property 2 above drove me to try a different approach -- the weakrefs may become invalid while the GObject may still be alive. That's a bit "surprising". Of course, if I could override weakref.ref() for GObject wrapper types, even that could be worked around... ;-) Thanks, [1] http://bugzilla.gnome.org/show_bug.cgi?id=320428 -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Weak references: dereference notification
On Wed, 2005-11-09 at 20:40 +0100, Ronald Oussoren wrote: > On 9-nov-2005, at 18:52, Gustavo J. A. M. Carneiro wrote: > > > Qua, 2005-11-09 às 09:23 -0800, Guido van Rossum escreveu: > >>>> Gustavo J. A. M. Carneiro wrote: > >>>>> I have come across a situation where I find the current weak > >>>>> references interface for extension types insufficient. > >>>>> > >>>>> Currently you only have a tp_weaklistoffset slot, pointing to a > >>>>> PyObject with weak references. However, in my case[1] I > >>>>> _really_ need > >>>>> to be notified when a weak reference is dereferenced. > >> > >> I find reading through the bug discussion a bit difficult to > >> understand your use case. Could you explain it here? If you can't > >> explain it you certainly won't get your problem solved! :-) > > > > This is a typical PyObject wrapping C object (GObject) problem. > > Both > > PyObject and GObject have independent reference counts. For each > > GObject there is at most one PyObject wrapper. > > > > When the refcount on the wrapper drops to zero, tp_dealloc is > > called. > > In tp_dealloc, and if the GObject refcount is > 1, I do something > > slightly evil: I 'resurect' the PyObject (calling PyObject_Init), > > create > > a weak reference to the GObject, and drop the "strong" reference. I > > call this a 'hibernation state'. > > Why do you do that? The only reasons I can think of are that you hope > to gain > some speed from this or that you want to support weak references to > the GObject. We want to support weak references to GObjects. Mainly because that support has always been there and we don't want/can't break API. And it does have some uses... > > For what its worth, in PyObjC we don't support weak references to the > underlying > Objective-C object and delete the proxy object when it is garbage > collected. > Objective-C also has reference counts, we increase that in the > constructor for > the proxy object and decrease it again in the destroctor. OK, but what if it is a subclass of a builtin type, with instance variables? What if the PyObject is GC'ed but the ObjC object remains alive, and later you get a new reference to it? Do you create a new PyObject wrapper for it? What happened to the instance variables? Our goal in wrapping GObject is that, once a Python wrapper for a GObject instance is created, it never dies until the GObject dies too. At the same time, once the python wrapper loses all references, it should not stop keeping the GObject alive. What happens currently, which is what I'm trying to change, is that there is a reference loop between PyObject and GObject, so that deallocation only happens with the help of the cyclic GC. But relying on the GC for _everything_ causes annoying problems: 1- The GC runs only once in a while, not soon enough if eg. you have an image object with several megabytes; 2- It makes it hard to debug reference counting bugs, as the symptom only appears when the GC runs, far away from the code that cause the problem in the first place; 3- Generally the GC has a lot more work, since every PyGTK object needs it, and a GUI app can have lots of PyGTK objects. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] Weak references: dereference notification
Qua, 2005-11-09 às 09:23 -0800, Guido van Rossum escreveu: > > > Gustavo J. A. M. Carneiro wrote: > > > > I have come across a situation where I find the current weak > > > > references interface for extension types insufficient. > > > > > > > > Currently you only have a tp_weaklistoffset slot, pointing to a > > > > PyObject with weak references. However, in my case[1] I _really_ need > > > > to be notified when a weak reference is dereferenced. > > I find reading through the bug discussion a bit difficult to > understand your use case. Could you explain it here? If you can't > explain it you certainly won't get your problem solved! :-) This is a typical PyObject wrapping C object (GObject) problem. Both PyObject and GObject have independent reference counts. For each GObject there is at most one PyObject wrapper. When the refcount on the wrapper drops to zero, tp_dealloc is called. In tp_dealloc, and if the GObject refcount is > 1, I do something slightly evil: I 'resurect' the PyObject (calling PyObject_Init), create a weak reference to the GObject, and drop the "strong" reference. I call this a 'hibernation state'. Now the problem. Suppose the user had a weak ref to the PyObject: 1- At certain point in time, when the wrapper is in hibernation state, the user calls the weak ref 2- It gets a PyObject that contains a weak reference to the GObject; 3- Now suppose whatever was holding the GObject ref drops its reference, which was the last one, and the GObject dies; 4- Now the user does something with the PyObject obtained through the weakref -> invalid memory access. The cause for the problem is that between steps 2 and 3 the wrapper needs to change the weak reference to the GObject to a strong one. Unfortunately, I don't get any notification that 2 happened. BTW, I fixed this problem in the mean time with a bit more of slightly evil code. I override tp_call of the standard weakref type :-P [...] > > and weakref.ref was smart enough to lookup this type and use it, only > > _then_ it could work. > > Looks what you're looking for is a customizable factory fuction. Sure, if weakref.ref could be such a factory, and could take "advice" on what type of weakref to use for each class. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Weak references: dereference notification
Qua, 2005-11-09 às 11:50 -0500, Jim Fulton escreveu: > Gustavo J. A. M. Carneiro wrote: > > Hello, > > > > I have come across a situation where I find the current weak > > references interface for extension types insufficient. > > > > Currently you only have a tp_weaklistoffset slot, pointing to a > > PyObject with weak references. However, in my case[1] I _really_ need > > to be notified when a weak reference is dereferenced. What happens now > > is that, when you call a weakref object, a simple Py_INCREF is done on > > the referenced object. It would be easy to implement a new slot to > > contain a function that should be called when a weak reference is > > dereferenced. Or, alternatively, a slot or class attribute that > > indicates an alternative type that should be used to create weak > > references: instead of the builtin weakref object, a subtype of it, so > > you can override tp_call. > > > > Does this sounds acceptable? > > Since you can now (as of 2.4) subclass the weakref.ref class, you should be > able to > do this yourself in Python. See for example, weakref.KeyedRef. I know I can subclass it, but it doesn't change anything. If people keep writing code like weakref.ref(myobj) instead of myweakref(myobj), it still won't work. I wouldn't want to have to teach users of the library that they need to use an alternative type; that seldom doesn't work. Now, if there was a place in the type that contained information like "for creating weak references of instances of this type, use this weakref class" and weakref.ref was smart enough to lookup this type and use it, only _then_ it could work. Thanks, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Weak references: dereference notification
Hello, I have come across a situation where I find the current weak references interface for extension types insufficient. Currently you only have a tp_weaklistoffset slot, pointing to a PyObject with weak references. However, in my case[1] I _really_ need to be notified when a weak reference is dereferenced. What happens now is that, when you call a weakref object, a simple Py_INCREF is done on the referenced object. It would be easy to implement a new slot to contain a function that should be called when a weak reference is dereferenced. Or, alternatively, a slot or class attribute that indicates an alternative type that should be used to create weak references: instead of the builtin weakref object, a subtype of it, so you can override tp_call. Does this sounds acceptable? Regards. [1] http://bugzilla.gnome.org/show_bug.cgi?id=320428 -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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 implicitconversions).
On Sat, 2005-10-29 at 10:56 +0200, "Martin v. Löwis" wrote: > Atsuo Ishimoto wrote: > > I'm +0.1 for non-ASCII identifiers, although module names should remain > > ASCII. ASCII identifiers might be encouraged, but as Martin said, it is > > very useful for some groups of users. > > Thanks for these data. This mostly reflects my experience with German > and French users: some people would like to use non-ASCII identifiers > if they could, other argue they never would as a matter of principle. > Of course, transliteration is more straight-forward. Not sure if anyone has made this point already, but unicode identifiers are also useful for math programs. The ability to directly type the math letters, like alpha, omega, etc., would actually make the code more readable, while still understandable by programmers of all nationalities. For instance, you could write: Δv = x1 - x0 if Δv < ε: return Instead of: delta_v = x1 - x0 if delta_v < epsilon: return But anyone that is supposed to understand the code will be able to read the delta and epsilon symbols. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] Coroutines, generators, function calling
On Tue, 2005-10-18 at 09:07 -0400, Jim Jewett wrote: > Suppose now I want to move the window animation to a function, to > factorize the code: > > def animate(win, steps): > for y in steps: > win.move(0, y*20) > yield Timeout(0.1) > > def show_message(msg): > win = create_window(msg) > animate(win, xrange(10)) # slide down > yield Timeout(3) > animate(win, xrange(10, 0, -1)) # slide up > win.destroy() > > This obviously doesn't work, because calling animate() produces > another generator, instead of calling the function. In coroutines > context, it's like it produces another coroutine, while all I wanted was > to call a function. > > I don't suppose there could be a way to make the yield inside the > subfunction have the same effect as if it was inside the function that > called it? Perhaps some special notation, either at function calling or > at function definition? > > - > > I may be missing something, but to me the answer looks like: > > def show_message(msg): > win = create_window(msg) > for v in animate(win, xrange(10)): # slide down > yield v > yield Timeout(3) > for v in animate(win, xrange(10, 0, -1)): # slide up > yield v > win.destroy() Sure, that would work. Or even this, if the scheduler would automatically recognize generator objects being yielded and so would run the the nested coroutine until finish: def show_message(msg): win = create_window(msg) yield animate(win, xrange(10)) # slide down yield Timeout(3) yield animate(win, xrange(10, 0, -1)) # slide up win.destroy() Sure, it could work, but still... I wish for something that would avoid creating a nested coroutine. Maybe I'm asking for too much, I don't know. Just trying to get some feedback... Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Coroutines, generators, function calling
There's one thing about coroutines using python generators that is still troubling, and I was wondering if anyone sees any potencial solution at language level... Suppose you have a complex coroutine (this is just an example, not so complex, but you get the idea, I hope): def show_message(msg): win = create_window(msg) # slide down for y in xrange(10): win.move(0, y*20) yield Timeout(0.1) # timeout yield Timeout(3) # slide up for y in xrange(10, 0, -1): win.move(0, y*20) yield Timeout(0.1) win.destroy() Suppose now I want to move the window animation to a function, to factorize the code: def animate(win, steps): for y in steps: win.move(0, y*20) yield Timeout(0.1) def show_message(msg): win = create_window(msg) animate(win, xrange(10)) # slide down yield Timeout(3) animate(win, xrange(10, 0, -1)) # slide up win.destroy() This obviously doesn't work, because calling animate() produces another generator, instead of calling the function. In coroutines context, it's like it produces another coroutine, while all I wanted was to call a function. I don't suppose there could be a way to make the yield inside the subfunction have the same effect as if it was inside the function that called it? Perhaps some special notation, either at function calling or at function definition? -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Making Queue.Queue easier to use
I'd just like to point out that Queue is not quite as useful as people seem to think in this thread. The main problem is that I can't integrate Queue into a select/poll based main loop. The other day I wanted extended a python main loop, which uses poll(), to be thread safe, so I could queue idle functions from separate threads. Obviously Queue doesn't work (no file descriptor to poll), so I just ended up creating a pipe, to which I send a single byte when I want to "wake up" the main loop to make it realize changes in its configuration, such as a new callback added. I guess this is partly an unix problem. There's no system call to say like "wake me up when one of these descriptors has data OR when this condition variable is set". Windows has WaitForMultipleObjects, which I suspect is quite a bit more powerful. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Pythonic concurrency - cooperative MT
On Fri, 2005-09-30 at 18:33 +0200, Antoine Pitrou wrote: > Hi Jp, > > Le vendredi 30 septembre 2005 à 12:20 -0400, Jp Calderone a écrit : > > "Advocating" might be putting it too strongly :) "Experimenting with" > > describes the current state of things most accurately. > > Ok :) > > > The problem it aims to solve is integration with cooperative threading > > systems which don't work very well. An example of such a loop is the > > wx event loop. > > > > Whenever a modal dialog is displayed or a menu is activated, wx's loop > > stops cooerating. That is wx's problem. Try PyGTK some day; I hear it's really good! ;-) > > This specific problem hides the more general problem, which is that GUI > and network activities have different typical latencies. As I explained > on the twisted ML, a GUI needs very good response times to feel friendly > (typically below 20 or even 10 ms.), whereas some network protocols have > non-trivial calculations which can go above 100 ms. With PyGTK a typical solution for this is to use a generator function executing an "idle function", which would make the non-trivial calculations, but yield control back to the main loop periodically, in order to process GUI events. For example, see the last code block in http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq23.020.htp > Moreover, you don't > want a sudden flood of network events to block events in the GUI. Process one event at a time, after each event give back control to the main loop, and give low priority to socket IO events. Problem solved. > > This is why even without considering wx's specificities, it is still > useful to keep GUI and network activities in separate threads. You are considering a scenario that seldom happens to design a solution that is far too complicated for most cases. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] Adding a conditional expression in Py3.0
On Sun, 2005-09-25 at 19:11 +0200, Reinhold Birkenfeld wrote: > Sokolov Yura wrote: > > Sorry for looking in every hole. > > Just a suggestion. > > > > A= condition and first or second > > problem is in case when first in (None,0,[],""). > > May be invent new operator 'take'. > > take - returns right operator when left evals to True and stops > > computing condidtional expression. > > Then we could write: > > > > A = condition take first or second. > > A = x==y take w or s > > A = z is not None and q!=12 take [] or allowable(z,q) take [(z,q)] or > > "Impossible" > > > > Ok, it might looks ugly. But may be not. > > One of the advantages of (if x then y else z) is that it doesn't require > the introduction of a new keyword (I think the "then" could be special- > cased like "as" in the import statement). This wouldn't look so bad either: (if x: y else: z) More realistic example: def greet(person=None): print "Hello %s" % (if person is None: "World" else: person) Not as compact as C's ?:, but more readable and intuitive. It's just like an if-else construct, but on a single line and () around to make it look like an expression instead of a statement. > > Reinhold > -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] Replacement for print in Python 3.0
On Sat, 2005-09-03 at 19:42 +0100, Paul Moore wrote: > On 9/3/05, James Y Knight <[EMAIL PROTECTED]> wrote: > > > > On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote: > > > > > So I think it's best to have two builtins: > > > > > > print(*args, **kws) > > > printf(fmt, *args, **kws) > > > > It seems pretty bogus to me to add a second builtin just to apply the > > % operator for you. I've always really liked that Python doesn't have > > separate xyzf functions, because formatting is an operation you can > > do directly on the string and pass that to any function you like. > > It's much cleaner... > > I have to agree. While I accept that Barry has genuine use cases for > the printf form, I don't quite see why %-formatting isn't enough. Is > the print-plus-% form so much less readable and/or maintainable? printf does avoid one extra set of () in many cases, making the code look and indent nicer. I take this chance to state my humble opinion. Please keep the print function print(), not writeln()! "printing stuff" is everyone's favorite anachronistic expression, even though the output doesn't go to a printer anymore. We all love it! I know Guido wanted a different name so that print() could be introduced in python 2 to allow a smooth transition to python 3, but the disadvantages in lost readability and familiarity by far outweigh the transition concerns imho. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] Withdrawn PEP 288 and thoughts on PEP 342
Hello,
I found your paper very interesting. I have also written a very
minimalistic white paper, mostly aimed at the PyGTK community, with a
small module for pseudo-threads using python generators:
http://www.gnome.org/~gjc/gtasklet/gtasklets.html
I don't have time to follow this whole discussion, but I leave it here
as another example of python pseudo-threads. I also am very much in
favour of having yield receive return values or exceptions, as this
would make pseudo-threads much more elegant. And I very much wish
python had this builtin or in std library.
In conjunction with pseudo-threads, I think a "python main loop"
implementation is fundamental. Such main loop with permit the programmer
to register callbacks for events, such as timeouts, IO conditions, idle
tasks, etc., such as one found glib (gtk+'s underlying library). I
already pointed out one such implementation that I use for one of my
projects, and it already has unit tests to prove that it works.
This is also related to the "deprecate asyncore/asynchat" discussions
going on earlier. IMHO, they should really be deprecated, and a
pseudo-threads solution could be used instead.
Anyway, I'd love to help more in this area, but unfortunately I don't
have time for these endless discussions... :P
Best regards.
On Fri, 2005-06-17 at 10:12 +0100, Michael Sparks wrote:
> At 08:24 PM 6/16/2005 -0400, Raymond Hettinger wrote:
> > As a further benefit, using
> >attributes was a natural approach because that same technique has long
> >been used with classes (so no new syntax was needed and the learning
> >curve was zero).
>
> On Friday 17 Jun 2005 02:53, Phillip J. Eby wrote:
> > Ugh. Having actually emulated co-routines using generators, I have to tell
> > you that I don't find generator attributes natural for this at all;
> > returning a value or error (via PEP 343's throw()) from a yield expression
> > as in PEP 342 is just what I've been wanting.
>
> We've been essentially emulating co-routines using generators embedded
> into a class to give us the equivalent of generator attributes. We've found
> this very natural for system composition. (Essentially it's a CSP type
> system,
> though with an aim of ease of use)
>
> I've written up my talk from ACCU/Python UK this year, and it's available
> here: http://www.bbc.co.uk/rd/pubs/whp/whp113.shtml
>
> I'll also be talking about it at Europython later this month.
>
> At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote:
> >Someone should really come up with some realistic coroutine examples
> >written using PEP 342 (with or without "continue EXPR").
>
> On Friday 17 Jun 2005 05:07:22, Phillip J. Eby wrote:
> > How's this?
> >
> >def echo(sock):
> >while True:
> >try:
> >data = yield nonblocking_read(sock)
> >yield nonblocking_write(sock, data)
> ... snip ...
>
> For comparison, our version of this would be:
>
> from Axon.Component import component
> from Kamaelia.SimpleServerComponent import SimpleServer
> class Echo(component):
>def mainBody(self):
> while True:
> if self.dataReady("inbox"):
> self.send(data,"outbox")
> yield1
>
> SimpleServer(protocol=EchoProtocol, port=1501).run()
>
>
> For more interesting pipelines we have:
>
> pipeline(TCPClient("127.0.0.1",1500),
> VorbisDecode(),
> AOAudioPlaybackAdaptor()
> ).run()
>
> Which works in the same way as a Unix pipeline. I haven't written the
> "pipegraph" or similar component yet that could allow this:
>
> graph(A=SingleServer("0.0.0.0", 1500),
>B=Echo(),
>layout = { "A:outbox": "B:inbox", "B:outbox" : "A:inbox" } )
>
> (Still undecided on API for that really, currently the above is a lot more
> verbose -)
>
> By contrast I really can't see how passing attributes in via .next() helps
> this approach in any way (Not that that's a problem for us :).
>
> I CAN see though it helps if you're taking the approach for generator
> composition if you're using twisted.flow (though I'll defer a good example
> for that to someone else since although I've been asked for a comparison in
> the past, I don't think I'm sufficiently twisted to do so!).
>
>
> Michael.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
___
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] Summer of Code: Developing complete SSL support for Python
On Sat, 2005-06-04 at 12:26 -0600, Shane Hathaway wrote:
> Florencio Cano Gabarda wrote:
> > I would like to do the new SSL module as good as possible. A piece of
> > art and efficiency if possible and obviusly having in mind all
> > programming standards.
>
> Guido and much of the community would certainly be appreciative of a new
> SSL module, especially if you can overcome the problems that plague
> M2Crypto.
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=95863
>
> I would say that the criteria for success would be:
>
> 1) A module, expected to be included in the standard library, that makes
> it easy to create both client and server SSL sockets.
>
> 2) No leaks or segfaults.
>
> 3) An API that any programmer can use without knowing much about
> cryptography.
>
> I want to be able to write code that's as simple as this:
>
> import socket
> import ssl
>
> def open_ssl_socket(address):
> base = socket.socket()
> base.connect(address)
> sock = ssl.client(base)
> return sock
>
> def run_server(port, handler, pki_files):
> keys = ssl.load_keys(pki_files)
> s = socket.socket()
> s.bind(('', port))
> s.listen(5)
> while True:
> base, address = s.accept()
> sock = ssl.server(base, keys)
> handler(sock)
> sock.close()
>
> "pki_filenames" in the example is a list of key files, certificate
> files, certificiate signing requests, and perhaps other PKI files. I
> want the ssl module to figure out for itself what each file means, so
> that I as a mere human can forget about those details. :-) However, if
> there's any ambiguity in the set of files provided, the SSL module
> should throw an exception rather than try to guess the intent.
>
> If you're ambitious, you could also figure out how to make this work
> with non-blocking sockets. I believe Twisted has made progress there.
4. In the socket module documentation:
ssl(
sock[, keyfile, certfile])
Initiate a SSL connection over the socket sock. keyfile is the
name of a PEM formatted file that contains your private key.
certfile is a PEM formatted certificate chain file. On success,
a new SSLObject is returned.
Warning: This does not do any certificate verification!
I would make it a top priority to enable certificate verification in
ssl sockets. I don't see the point in doing SSL without certificate
verification. It's just false security. Maybe adding a callback asking
the application what to do if certificate validation fails, so that
application writers can show a GUI dialogue or something like that...
Best regards.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic
___
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] PEP 340: propose to get rid of 'as' keyword
On Wed, 2005-05-04 at 13:08 -0600, Shane Hathaway wrote: > Gustavo J. A. M. Carneiro wrote: > > In PEP 340 I read: > > > > block EXPR1 as VAR1: > > BLOCK1 > > > > I think it would be much clearer this (plus you save one keyword): > > > > block VAR1 = EXPR1: > > BLOCK1 > > I think you misunderstood the statement. EXPR1 creates an iterator, > then VAR1 iterates over the values returns by the iterator. VAR1 never > sees the iterator. Using your syntax would reinforce the > misinterpretation that VAR1 sees the iterator. In that case, block VAR1 in EXPR1: BLOCK1 And now I see how using 'for' statements (perhaps slightly changed) turned up in the discussion. Sorry for the noise. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] PEP 340: propose to get rid of 'as' keyword
I have not read every email about this subject, so sorry if this has already been mentioned. In PEP 340 I read: block EXPR1 as VAR1: BLOCK1 I think it would be much clearer this (plus you save one keyword): block VAR1 = EXPR1: BLOCK1 Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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] a bunch of Patch reviews
On Mon, 2005-01-17 at 23:12 +0100, "Martin v. Löwis" wrote: > Gustavo J. A. M. Carneiro wrote: > > If someone could take a look at: > > > > [ 1069624 ] incomplete support for AF_PACKET in socketmodule.c > > > The rule applies: five reviews, with results posted to python-dev, > and I will review your patch. Oh... sorry, I didn't know about any rules. /me hides in shame. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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] a bunch of Patch reviews
If someone could take a look at:
[ 1069624 ] incomplete support for AF_PACKET in socketmodule.c
I have to ship my own patched copy of the socket module because of
this... :|
On Sun, 2005-01-16 at 17:08 +0100, Irmen de Jong wrote:
> Hello
> I've looked at one bug and a bunch of patches and
> added a comment to them:
>
> (bug) [ 1102649 ] pickle files should be opened in binary mode
> Added a comment about a possible different solution
>
> [ 946207 ] Non-blocking Socket Server
> Useless, what are the mixins for? Recommend close
>
> [ 756021 ] Allow socket.inet_aton('255.255.255.255') on Windows
> Looks good but added suggestion about when to test for special case
>
> [ 740827 ] add urldecode() method to urllib
> I think it's better to group these things into urlparse
>
> [ 579435 ] Shadow Password Support Module
> Would be nice to have, I recently just couldn't do the user
> authentication that I wanted: based on the users' unix passwords
>
> [ 1093468 ] socket leak in SocketServer
> Trivial and looks harmless, but don't the sockets
> get garbage collected once the request is done?
>
> [ 1049151 ] adding bool support to xdrlib.py
> Simple patch and 2.4 is out now, so...
>
>
>
> It would be nice if somebody could have a look at my
> own patches or help me a bit with them:
>
> [ 1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice
> [ 1103213 ] Adding the missing socket.recvall() method
> [ 1103350 ] send/recv SEGMENT_SIZE should be used more in socketmodule
> [ 1062014 ] fix for 764437 AF_UNIX socket special linux socket names
> [ 1062060 ] fix for 1016880 urllib.urlretrieve silently truncates dwnld
>
> Some of them come from the last Python Bug Day, see
> http://www.python.org/moin/PythonBugDayStatus
>
>
> Thank you !
>
> Regards,
>
> --Irmen de Jong
> ___
> 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/gjc%40inescporto.pt
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
smime.p7s
Description: S/MIME cryptographic signature
___
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] an idea for improving struct.unpack api
On Thu, 2005-01-06 at 13:17 +, Michael Hudson wrote: > Ilya Sandler <[EMAIL PROTECTED]> writes: > > > A problem: > > > > The current struct.unpack api works well for unpacking C-structures where > > everything is usually unpacked at once, but it > > becomes inconvenient when unpacking binary files where things > > often have to be unpacked field by field. Then one has to keep track > > of offsets, slice the strings,call struct.calcsize(), etc... > > IMO (and E), struct.unpack is the primitive atop which something more > sensible is built. I've certainly tried to build that more sensible > thing at least once, but haven't ever got the point of believing what > I had would be applicable to the general case... maybe it's time to > write such a thing for the standard library. I've been using this simple wrapper: def stream_unpack(stream, format): return struct.unpack(format, stream.read(struct.calcsize(format))) It works with file-like objects, such as file, StringIO, socket.makefile(), etc. Working with streams is useful because sometimes you don't know how much you need to read to decode a message in advance. Regards. > > Cheers, > mwh > -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. smime.p7s Description: S/MIME cryptographic signature ___ 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
