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 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 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 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. PEP8 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. /PEP8 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
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
[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] 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
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] 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
[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] 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
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=showfile=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] 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
[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] 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
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] 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
