Re: [Python-Dev] Interning string subtype instances
Greg Ewing schrieb: > It's certainly possible to tell very easily whether > a string is interned -- there's a PyString_CHECK_INTERNED > macro that tests a field in the string object header. > But, I can't find anywhere that it's used in the core, > apart from the interning code itself and the string > alloc/dealloc code. > > Can anyone shed any light on this? It seems to me that > by not using this information, only half the benefit of > interning is being achieved. You seem to assume that checking this property would improve performance. I find that questionable; as always with performance and optimization, one cannot know until it has been benchmarked. My guess is that - the cases you want to cover are comparably infrequent (compared to the total number of richcompare invocations) - checking the additional field always may cause a performance loss, not a performance gain, because of the additional tests. If you want to sure, you need to make some measurements (e.g: what is the percentage of EQ and NE invocations, in how many cases are both strings interned, and in what percentage of these cases are they not the same string). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
Greg Ewing schrieb:
> Brett Cannon wrote:
>> On 2/12/07, Collin Winter <[EMAIL PROTECTED]> wrote:
>>> 2) {BinOp,AugAssign,BoolOp,etc}.op
>> I can't think of a reason, off the top of my head, why they can't be
>> singletons.
>
> Why not just use interned strings?
Because it's generated code. It has to follow rules, and it would
be good if there were few exceptions.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
Collin Winter schrieb:
> 2) It turned out that {BinOp, BoolOp,AugAssign,etc}.op were already
> singleton instances of their respective classes. I've changed
> asdl_c.py to no longer emit the *_singleton names and to use the
> corresponding *_type types in their place, which will enable me to
> write "node.op is _ast.Add", etc.
I don't really like this - it's inconsistent. I'd rather prefer
if the singletons where exposed under a name, e.g.
_ast.Add.singleton, or _ast.add (if that doesn't cause conflicts).
> 3) Adding an Else node was a little more involved, but it proved
> do-able. TryFinally.orelse, While.orelse, For.orelse and If.orelse can
> now be either None or an instance of Else. Else instances have a
> 'body' attribute, which is a sequence of statements.
I still can't see the need (we don't have line numbers for every
token in the AST), but I can't see anything wrong with it, either
(except for the change in the structure, of course, but that will
happen, anyway).
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
Greg Ewing schrieb:
> It would seem even easier (and a lot faster) to use an
> array to go from C enum --> some object, which could
> as well be an interned string as anything else.
Have you actually looked at the code? How could it be
faster than
PyObject* ast2obj_boolop(boolop_ty o)
{
switch(o) {
case And:
Py_INCREF(And_singleton);
return And_singleton;
case Or:
Py_INCREF(Or_singleton);
return Or_singleton;
}
return NULL; /* cannot happen */
}
Not sure what interned strings have to do with it.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
Greg> [EMAIL PROTECTED] wrote: Greg> for (x in seq1, y in seq2): >> That's already valid syntax though. Greg> No, it's not... for (x in seq1, y in seq2): Greg>File "", line 1 Greg> for (x in seq1, y in seq2): Greg>^ Greg> SyntaxError: invalid syntax Ah, yeah. Misread it and just focused on the bit that looked like a tuple... Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
Hi Michael,
On Tue, Feb 13, 2007 at 11:55:46PM +, Michael Foord wrote:
> > x = *('variable%d' % n)
> > f(a, b, *('keyword%d' % n) = c)
> > class *('33strangename'):
> > pass
> > def *(funcname)(x, y, *(argname), *args, **kwds):
> > pass
> > import *modname as mymodule
> >
> Are you for these uses or mocking them ? Some of them look interesting...
I don't actually have any strong opinion, I was just exploring all the
places in the grammar that say NAME... Some of the above are definitely
just absurd. In general I am failing to see much the point of syntax
extensions, so I'll step out of this discussion again.
Armin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary: rejection of 'dynamic attribute' syntax
Guido van Rossum wrote: > This seems to be the overwhelming feedback at this point, so I'm > withdrawing my support for the proposal. I hope that Ben can write up > a PEP and mark it rejected, to summarize the discussion; it's been a > useful lesson. The feedback is clear, yes. The "new syntax seems like overkill" camp has become dominant, and I certainly think these are very valid arguments. Gentle support remains scattered here and there, but the consensus has emerged. I will summarise all this into the PEP and mark it as rejected. Still, the discussion was useful, I thought. Thanks for the interest. To respond, for the record, to some of the specific points recently raised: [EMAIL PROTECTED]: > I really, really wish that every feature proposal for Python had to meet > some burden of proof [...]. I suspect this would kill 90% of "hey > wouldn't this syntax be neat" proposals on day zero [...] This is what I understood the initial posting to python-ideas to be about. If the feedback from there had been "that's a stupid idea", then that would have been the end of it. I think it's a good thing that there's the python-ideas mechanism for speculative suggestions. I like the "attrview" or "attrs" wrapper idea, with the example given by Larry Hastings: > setattr(self, method_name, getattr(self.metadata, method_name)) > [...] would be: > attrview(self)[method_name] = attrview(self.metadata)[method_name] As others point out, it's very clean, captures the intended uses well, and has the great advantage of having easily-added backwards compatibility. I might start using it :-) If the people who suggested and refined this were to put it in a PEP, I'd be in favour. Guido van Rossum wrote: > I missed discussion of the source of the 1%. Does it slow down pystone > or other benchmarks by 1%? That would be really odd, since I can't > imagine that the code path changes in any way for code that doesn't > use the feature. Is it that the ceval main loop slows down by having > two more cases? That seems to be it, yes. I tested this by leaving the grammar, compilation, and AST changes in, and conditionally compiling just the three extra cases in the ceval main loop. Measurements were noisy though, as Josiah Carlson has also experienced: > I've found variations of up to 3% in benchark times that seemed to be > based on whether I was drinking juice or eating a scone while working. I'm afraid I can't remember what I was eating or drinking at the time I did my tests. (Thanks also for the kind words regarding my summaries etc. Having caused all the fuss in the first place I felt obliged to try to make myself a bit useful :-) Ben. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On Wed, Feb 14, 2007, [EMAIL PROTECTED] wrote: > > As I said, I don't have time to write the PEPs myself, but I might fix > some specific bugs if there were a clear set of issues preventing this > from moving forward. Better integration with the standard library > would definitely be a big win for both Twisted and Python. Here's where I'm coming from: My first experience with Twisted was excellent: I needed a web server in fifteen minutes to do my PyCon presentation, and it Just Worked. My second experience with Twisted? Well, I didn't really have one. My first experience was Twisted 1.1, and when I tried installing 2.0 on my Mac (about 1.5 years ago), it just didn't work. Combined with the difficulty of using the documentation and the fact that I was in a hurry, I rejected the Twisted solution. (My company needed an FTP server that did a callback every time a file got uploaded -- something that I expect would be very simple for Twisted.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
Oleg Broytmann wrote: > On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote: >> Python further away from the "Computer Programming for Everyone" arena >> and closer to the "Systems Programming for Clever Individuals" camp. > >That's because Python is being developed by "Clever Individuals" and not > by "Computer Programming for Everyone Committee". > I agree that the developers are Clever Individuals. So clever, in fact, that they realise Python needs to be as approachable as possible, not a language for them alone. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nb_inplace_power ternary?
The same way += et al. are in-place: it would ask 'x' to modify itself, if it can. If not, no harm done. (It would be called as 'x = ipow(x, n, 10)' of course, just like 'x += n' is really 'x = x.__iadd__(n)') On 2/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Greg Ewing schrieb: >> What could the syntax for that be? > > It wouldn't be a syntax, just a function, e.g. > >ipow(x, n, 10) In what way would that be inplace? A function cannot rebind the variables it gets as parameters. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/thomas%40python.org -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary: rejection of 'dynamic attribute' syntax
Ben North wrote: [...] > Guido van Rossum wrote: >> I missed discussion of the source of the 1%. Does it slow down pystone >> or other benchmarks by 1%? That would be really odd, since I can't >> imagine that the code path changes in any way for code that doesn't >> use the feature. Is it that the ceval main loop slows down by having >> two more cases? > > That seems to be it, yes. I tested this by leaving the grammar, > compilation, and AST changes in, and conditionally compiling just the > three extra cases in the ceval main loop. Measurements were noisy > though, as Josiah Carlson has also experienced: > >> I've found variations of up to 3% in benchark times that seemed to be >> based on whether I was drinking juice or eating a scone while working. > > I'm afraid I can't remember what I was eating or drinking at the time I > did my tests. > A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing. One of the interesting facts to emerge from the Need for Speed sprint last year is that architectural complexities at many levels make it extremely difficult nowadays to build a repeatable benchmark of any kind. > (Thanks also for the kind words regarding my summaries etc. Having > caused all the fuss in the first place I felt obliged to try to make > myself a bit useful :-) > Your management of the discussion process has indeed been exemplary. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
On Wed, Feb 14, 2007 at 03:24:30PM +, Steve Holden wrote: > Oleg Broytmann wrote: > > On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote: > >> Python further away from the "Computer Programming for Everyone" arena > >> and closer to the "Systems Programming for Clever Individuals" camp. > > > >That's because Python is being developed by "Clever Individuals" and not > > by "Computer Programming for Everyone Committee". > > > I agree that the developers are Clever Individuals. So clever, in fact, > that they realise Python needs to be as approachable as possible, not a > language for them alone. Anyway I don't believe it's possible to create a CP4E language without a "CP4E Steering Committee", and I think such committee it Python land is... dormant at present... Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary: rejection of 'dynamic attribute' syntax
Steve Holden schrieb: > Ben North wrote: > [...] >> Guido van Rossum wrote: >>> I missed discussion of the source of the 1%. Does it slow down pystone >>> or other benchmarks by 1%? That would be really odd, since I can't >>> imagine that the code path changes in any way for code that doesn't >>> use the feature. Is it that the ceval main loop slows down by having >>> two more cases? >> >> That seems to be it, yes. I tested this by leaving the grammar, >> compilation, and AST changes in, and conditionally compiling just the >> three extra cases in the ceval main loop. Measurements were noisy >> though, as Josiah Carlson has also experienced: >> >>> I've found variations of up to 3% in benchark times that seemed to be >>> based on whether I was drinking juice or eating a scone while working. >> >> I'm afraid I can't remember what I was eating or drinking at the time I >> did my tests. >> > A further data point is that modern machines seem to give timing > variabilities due to CPU temperature variations even if you always eat > exactly the same thing. > > One of the interesting facts to emerge from the Need for Speed sprint > last year is that architectural complexities at many levels make it > extremely difficult nowadays to build a repeatable benchmark of any kind. My personal experience using a dual core machine (on WinXP) is that timing results become much more reproducible. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
On 2/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Tristan is correct: this should be a patch against Twisted, or perhaps as a > separate library that could implement a reactor. I think there is some confusion here. I am not writing a competing event driven mechanism. What I was doing was feeling out whether there was any interest in better support for asynchronous calls. You are right. This should not have been on this list. It should have been on python-ideas, but I replied here because Dustin started the discussion here and I thought if a generator based microthreading solution were to be implemented, it could also benefit from better asynchronous support so brought it into the discussion. After all, if microthreading was in the Python distribution, then it makes sense to make other general improvements which make them more useful. What I meant to suggest that Twisted could be based on was the asynchronous file IO support using IOCP. Especially because Tristan implied that Twisted's own IOCP reactor was incomplete. I did not say this clearly. Yes I have looked at Twisted. It was the first place I looked, several months ago, and what drew me to it was the IOCP reactor. However as I also explained in my reply to Tristan it is not suitable for my needs. It is a large dependency and it is a secondary framework. And I did not feel the need to verify the implication that it wasn't ready because this matched my own recollections. But I hope you realise that asserting that things should be within Twisted without giving any reason, especially when the first person saying it just stated that the matching work in Twisted wasn't even ready, feels like Twisted is trying to push itself forward by bullying people to work within it whenever something can be asserted as laying within whatever domain it is which Twisted covers. Even if it doesn't suit their needs. I don't think Tristan intended that, but when followed up with your reply and JP's interesting response to Greg, it feels like it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
* Richard Tew <[EMAIL PROTECTED]> [2007-02-14 16:49:03 +]: > I am not writing a competing event driven mechanism. What I was doing > was feeling out whether there was any interest in better support for > asynchronous calls. I interpreted your suggestions as being about enhancing asyncore with IOCP (or similar); sure, asyncore is already a "competing" event driven mechanism, but for all intents and purposes it is "dead" as there is not much in the way of active development on it, and a relatively small remaining user base. You seemed to be suggesting that asyncore be revived by extending the implementation, as well as sprinkling some generator / tasklets / channels / etc. sugar on top of it. > But I hope you realise that asserting that things should be within > Twisted without giving any reason, especially when the first person > saying it just stated that the matching work in Twisted wasn't even > ready, feels like Twisted is trying to push itself forward by bullying > people to work within it whenever something can be asserted as > laying within whatever domain it is which Twisted covers. I don't really think it's "bullying" to suggest that improving Twisted, rather than reimplementing Twisted's core with a brand new implementation slapped straight into the Python stdlib, is counterproductive. > Even if it doesn't suit their needs. I don't think Tristan intended > that, but when followed up with your reply and JP's interesting > response to Greg, it feels like it. The gist of my message was "Instead of reimplementing the Twisted reactor, probably poorly, just use Twisted", based on my understanding of what your suggestion was. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nb_inplace_power ternary?
Thomas Wouters schrieb: > > The same way += et al. are in-place: it would ask 'x' to modify itself, > if it can. If not, no harm done. (It would be called as 'x = ipow(x, n, > 10)' of course, just like 'x += n' is really 'x = x.__iadd__(n)') I think this would violate the policy that a mutating function shouldn't give the object being modified as the result - just as list.reverse doesn't return the list, in addition to reversing it in-place. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nb_inplace_power ternary?
Sure, and I don't know if anyone will ever want ipow() -- but I've never seen real code use the three-argument pow() either. The fact is that all the in-place modifying hooks return the result (which may or may not be self, and may or may not be mutated) so an in-place three-argument pow() would have to do the same. I would prefer keeping the similarity between __ipow__ and __pow__, although I don't care if that means keeping the always-unused third argument to __ipow__ (which isn't really in the way, after all) or adding a new hook for the three-argument pow(). On 2/14/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Thomas Wouters schrieb: > > The same way += et al. are in-place: it would ask 'x' to modify itself, > if it can. If not, no harm done. (It would be called as 'x = ipow(x, n, > 10)' of course, just like 'x += n' is really 'x = x.__iadd__(n)') I think this would violate the policy that a mutating function shouldn't give the object being modified as the result - just as list.reverse doesn't return the list, in addition to reversing it in-place. Regards, Martin -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nb_inplace_power ternary?
Thomas Wouters schrieb: > > Sure, and I don't know if anyone will ever want ipow() -- but I've never > seen real code use the three-argument pow() either. The fact is that all > the in-place modifying hooks return the result (which may or may not be > self, and may or may not be mutated) so an in-place three-argument pow() > would have to do the same. I would prefer keeping the similarity between > __ipow__ and __pow__, although I don't care if that means keeping the > always-unused third argument to __ipow__ (which isn't really in the way, > after all) or adding a new hook for the three-argument pow(). It's in the way in the sense that slot_nb_inplace_power discards its third argument silently. That shouldn't happen, so I still prefer removing it throughout. Would you volunteer adding to fix that? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
Greg Ewing <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > def intern(st): > > ... > > > > If I remember the implementation of intern correctly, that's more or > > less what happens under the covers. > > That doesn't quite give you everything that real interning > does, though. The string comparison method knows when both > strings are interned, so it can compare them quickly > whether they are equal or not. Your version could detect > equal strings quickly, but not unequal strings. Assuming that dictionaries and the hash algorithm for strings is not hopelessly broken, I believe that one discovers quite quickly when two strings are not equal. Simple testing seems to confirm this, but I didn't work too hard to disprove it either. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
Tristan Seligmann <[EMAIL PROTECTED]> wrote: > * Richard Tew <[EMAIL PROTECTED]> [2007-02-14 16:49:03 +]: > > > I am not writing a competing event driven mechanism. What I was doing > > was feeling out whether there was any interest in better support for > > asynchronous calls. > > I interpreted your suggestions as being about enhancing asyncore with > IOCP (or similar); sure, asyncore is already a "competing" event driven > mechanism, but for all intents and purposes it is "dead" as there is not > much in the way of active development on it, and a relatively small > remaining user base. You seemed to be suggesting that asyncore be > revived by extending the implementation, as well as sprinkling some > generator / tasklets / channels / etc. sugar on top of it. It's not dead; much code is still being developed for it, and I recently stepped up as its new maintainer. One of the reasons it's not getting huge new feature additions is generally because it has all of the functionality necessary to get someone started in asynchronous socket programming. That's its purpose. Could it be expanded to support IOCP on Windows? Sure. Is it necessary for its survival? No. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
Greg Ewing wrote: > Can anyone shed any light on this? It seems to me that > by not using this information, only half the benefit of > interning is being achieved. If I understand your question correctly, you're saying "why doesn't string comparison take advantage of interned strings?" If so, the answer is "it does". Examine string_richcompare() in stringobject.c, and PyUnicode_compare() in unicodeobject.c. Both functions compare the pointers of the two objects in case they are literally the same object, and if so skip all the expensive comparison code. Interned strings which have the same value are likely to be (are guaranteed to be?) the same object. And there you are. If that's not the question you are asking, I'll be quiet, 'cause it seems like other people understand what you're talking about. Cheers, /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
Larry Hastings schrieb: > If I understand your question correctly, you're saying "why doesn't > string comparison take advantage of interned strings?" If so, the > answer is "it does". Examine string_richcompare() in stringobject.c, > and PyUnicode_compare() in unicodeobject.c. Both functions compare the > pointers of the two objects in case they are literally the same object, > and if so skip all the expensive comparison code. Interned strings > which have the same value are likely to be (are guaranteed to be?) the > same object. And there you are. > > If that's not the question you are asking, I'll be quiet, 'cause it > seems like other people understand what you're talking about. The question was similar: "Why doesn't it take the maximum advantage?" Interned strings that are equal are guaranteed to be identical. So if strings are not identical and both interned, it could infer that they can't be equal, but currently doesn't infer so (instead, it compares length and contents in this case). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary: rejection of 'dynamic attribute' syntax
On 01:04 pm, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED]: >> I really, really wish that every feature proposal for Python had to meet >> some burden of proof [...]. I suspect this would kill 90% of "hey >> wouldn't this syntax be neat" proposals on day zero [...] > >This is what I understood the initial posting to python-ideas to be >about. If the feedback from there had been "that's a stupid idea", then >that would have been the end of it. I think it's a good thing that >there's the python-ideas mechanism for speculative suggestions. Discussion, with any audience, no matter how discerning, isn't really going to be a useful filter unless the standards of that audience are clear. What I was trying to say there is that the proposal of new ideas should not begin with "Hey, I think this might be 'good'" - that's too ill defined. It should be, "I noticed (myself/my users/my students/other open source projects) writing lots of code that looks like *this*, and I think it would be a real savings if it could look like *that*, instead". Some back-of-the-envelope math might be nice, in terms of savings of lines of code, or an explanation of the new functionality that might be enabled by a feature. More than the way proposals should work, I'm suggesting that the standards of the community in _evaluating_ to the proposals should be clearer. The cost-benefit analysis should be done in terms of programmer time, or ease of learning, or integration possibilities, or something. It doesn't *necessarily* have to be in terms of "lines of code saved", but especially for syntax proposals, that is probably a necessary start. It's fine to have some aesthetic considerations, but there's a lot more to Python than aesthetics, and right now it seems like the majority of posts coming into threads like this one are "I don't like the proposed ':==|', it's ugly. How about '?!?+' instead?" The short version of this is that any feature should describe what task it makes easier, for whom, and by how much. This description should be done up front, so that the discussion can center around whether than analysis is correct and whether it is worth the ever-present tradeoff against upgrade headaches. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On 03:32 pm, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED] wrote: >>When you boil it down, Twisted's event loop ... >But that is exactly the problem I have with Twisted. For HTTP ... >From that word on out, you have completely lost the plot. I am talking about Twisted's _event loop_. I specifically mentioned that the higher levels (and specifically "web") are separate, and can be discussed separately. If there were interest in porting the simpler XXXHTTPServer APIs in the stdlib to be event-driven and work with a Twisted-style event loop, it would be a relatively simple hack. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On 02:22 pm, [EMAIL PROTECTED] wrote: >On Wed, Feb 14, 2007, [EMAIL PROTECTED] wrote: >> >> As I said, I don't have time to write the PEPs myself, but I might fix >> some specific bugs if there were a clear set of issues preventing this >> from moving forward. Better integration with the standard library >> would definitely be a big win for both Twisted and Python. > >Here's where I'm coming from: > >My first experience with Twisted was excellent: I needed a web server in >fifteen minutes to do my PyCon presentation, and it Just Worked. > >My second experience with Twisted? Well, I didn't really have one. Thanks for the feedback, Aahz... I'm a little confused, though. Is this just a personal anecdote, or were you trying to make a larger point about Twisted's suitability for the stdlib? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
[EMAIL PROTECTED] schrieb: > On 02:20 am, [EMAIL PROTECTED] wrote: > >> If Twisted is designed so that it absolutely *has* to use its own >> special event mechanism, and everything else needs to be modified >> to suit its requirements, then it's part of the problem, not part >> of the solution. > > I've often heard this complaint, usually of the form "that's > twisted-specific". The thing is, Twisted isn't specific. Its event > mechanism isn't "special". In fact it's hard to imagine how it might > be made less "special" than it currently is. > > Whatever your event dispatch mechanism, *some* code has to be > responsible for calling the OS API of select(), > WaitForMultipleEvents(), g_main_loop_run(), or whatever. Twisted > actually imposes very few requirements for code to participate in > this, and was designed from day one specifically to be a generalized > mainloop mechanism which would not limit you to one underlying > multiplexing implementation, event-dispatch mechanism, or operating > system if you used its API. When I last looked at twisted (that is several years ago), there were several reactors - win32reactor, wxreactor, maybe even more. And they didn't even work too well. The problems I remember were that the win32reactor was limited to a only handful of handles, the wxreactor didn't process events when a wx modal dialog boy was displayed, and so on. Has this changed? Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
On 04:49 pm, [EMAIL PROTECTED] wrote: >On 2/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>Tristan is correct: this should be a patch against Twisted, or perhaps as a >>separate library that could implement a reactor. > >I think there is some confusion here. Quite. >I am not writing a competing event driven mechanism. What I was doing >was feeling out whether there was any interest in better support for >asynchronous calls. Perhaps you could describe what you were proposing a bit better, because both to Tristan and myself, it sounded (and frankly, still sounds) like you were describing that would directly replace Twisted's mainloop core API. "asynchronous calls" is a very vague term with at least three completely separate definitions. >Yes I have looked at Twisted. It was the first place I looked, several >months ago, and what drew me to it was the IOCP reactor. However >as I also explained in my reply to Tristan it is not suitable for my >needs. As far as I can tell, you still haven't even clearly expressed what your needs are, let alone whether or not Twisted is suitable. In the reply you're citing, you said that "this" sounded like something "low level" that "twisted would be written on top of" - but the "this" you were talking about, based on your previous messages, sounded like monkeypatching the socket and asyncore modules to provide asynchronous file I/O based on the platform-specific IOCP API for Windows. Twisted can already provide that functionality in a _much_ cleaner fashion already, although you might need to edit some code or monkeypatch some objects specifically to get asynchronous file I/O, at least Twisted is *designed* for such applications. To quote you from the original message that Tristan replied to: >> I can't go into low level details because I do not have the necessary >> experience or knowledge to know which approach would be best. ... >> I of course have no concept of how this might be done on other platforms. As someone who _does_ have the necessary experience and knowledge, I can tell you that Twisted *IS* the "one stop shop" for events that you're describing. I do know how one would do such a thing on other platforms and it is not a simple task - so much so that async file I/O is still not available in Twisted today. >It is a large dependency and it is a secondary framework. Has it occurred to you that it is a "large" dependency not because we like making bloated and redundant code, but because it is doing something that is actually complex and involved? >And I did not feel the need to verify the implication that it wasn't >ready because this matched my own recollections. It meaning... Twisted? Twisted's IOCP support? Ready for... what? IOCPReactor definitely not up to the standard of much of the rest of the code in Twisted, but it's clearly ready for _something_ since BitTorrent uses it. >But I hope you realise that asserting that things should be within >Twisted without giving any reason, I have suggested that work proceed in Twisted rather than in Python because adding async file I/O to Twisted would be much easier than adding an entirely new event-loop core to Python, and then adding async file I/O to *that*. I thought that I provided several reasons before as well, but let me state them as clearly as I can here. Twisted is a large and mature framework with several years of development and an active user community. The pluggable event loop it exposes is solving a hard problem, and its implementation encodes a lot of knowledge about how such a thing might be done. It's also tested on a lot of different platforms. Writing all this from scratch - even a small subset of it - is a lot of work, and is unlikely to result in something robust enough for use by all Python programs without quite a lot of effort. It would be a lot easier to get the Twisted team involved in standardizing event-driven communications in Python. Every other effort I'm aware of is either much smaller, entirely proprietary, or both. Again, I would love to be corrected here, and shown some other large event-driven framework in Python that I was heretofore unaware of. Standardization is much easier to achieve when you have multiple interested parties with different interests to accommodate. As Yitzhak Rabin used to say, "you don't engage in API standardization with your friends, you engage in API standardization with your enemies" - or... something like that. >especially when the first person >saying it just stated that the matching work in Twisted wasn't even >ready, feels like Twisted is trying to push itself forward by bullying >people to work within it whenever something can be asserted as >laying within whatever domain it is which Twisted covers. You say that you weren't proposing an alternate implementation of an event loop core, so I may be reacting to something you didn't say at all. However, again, at least Tristan t
Re: [Python-Dev] Any value in setting up pybots for py3k?
In addition to the breakages because of Python 3.0 features and bugs, there currently isn't a way to deal with most of those breakages, except by forking your code in 2.x and 3.x versions. You can't write a non-bare except statement that works in 2.x and 3.x, for instance. I'd say it's still too early, but we're getting there -- most of the 3.0 features are in, and the 2.6-compatibility-mode is being worked on (slowly, but still.) When they're in, people could have a buildbot setup that tests the same source in 3.0-to-be and 2.6-to-be (and older released Python versions, if they really want to see a lot of errors.) such a setup would probably catch a lot of 3.0and 2.6 bugs, too ;-) On 2/13/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Grig Gheorghiu schrieb: > So is there any value or interest in setting up a svn notification > hook for py3k commits that would go to the pybots buildbot master? A similar question is whether there should be buildbots for Python 3 itself (i.e. running the test suite). Even for that, it was considered too early. I would expect that packages break in massive ways because of the by-design incompatibilities. It would be good to get an estimate of what the impact is, but having a build once a month might be more than enough. To fully study the problems, one has to install Python 3 locally, anyway, and then run the package in question on top of that. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/thomas%40python.org -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On 08:52 pm, [EMAIL PROTECTED] wrote: >When I last looked at twisted (that is several years ago), there were >several reactors - win32reactor, wxreactor, maybe even more. Yes. That's intentional. Each of those systems offers its own event loop, and each reactor implements the basic operations in terms of those loops. They all have the same API. Application code does 'from twisted.internet import reactor; reactor.listenTCP', 'reactor.callLater', etc. Only the very top-most level decides which reactor the application will use. >And they >didn't even work too well. The problems I remember were that the win32reactor >was limited to a only handful of handles, the wxreactor didn't process >events when a wx modal dialog boy was displayed, and so on. Has this changed? win32eventreactor is limited to 64 handles because WaitForMultipleObjects is limited to 64 handles. wxreactor's event loop is ghastly and actually did pause when a modal dialog box is displayed (that has since been fixed). Process support on win32 now works in the default select reactor as well as the gtk reactor, so win32reactor is mostly a curiosity at this point (useful mainly if you want to implement your own GDI-based GUI, as PyUI did at one point), and its limitations are not as serious for Twisted as a whole. In other words, Twisted exposes the platform limitations in its platform-specific event loop implementations, and only works around them where it's possible to do so without masking platform functionality. For servers, the epoll, poll, and select reactors work just fine. The select reactor does have a maximum of FD_SETSIZE simultaneous sockets as well, but it is very easy to switch reactors if you need something more scalable. For clients, the best GUI toolkit for Twisted applications at this point is GTK, but WX, QT and Cocoa can all be made to work with a minimum of hassle. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] pre-PEP: Default Argument Expressions
Another thing I don't like about this default argument proposal is that using it in any non-trivial way would tend to put implementation details of the function up in the header, which should be reserved for info describing the calling signature. The following example from the PEP is an extreme instance of this: > def bar(b=my_sum((["b"] * (2 * 3))[:4])): > print b -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
Jean-Paul Calderone wrote: > Greg, productive discussion is not furthered by the > unsupported statement of one position or another. Sorry, I'll expand on that a bit. The "problem" I was referring to is the turf wars between all the event-driven frameworks that all want to do things their own way. Solving that is going to require them to give up control and be willing to agree on a standard. It seems reasonable to consider making a suitably enhanced version of asyncore the standard, because it's small and it's already in the stdlib. Someone seemed to be claiming that it would be too hard to rework Twisted's event loop to use anything else, so we had better just use Twisted instead of asyncore, which sounded like a turf-war kind of statement. (That's what I meant by "part of the problem" -- I should really have said it's an *example* of the problem.) From a later post, it seems the main concern is that expanding asyncore to the point where it could support Twisted would involve reinventing most of Twisted's event loop implementation. That's a reasonable point to make, and I don't see anything wrong with examining Twisted's implementation to see what can be used. Whether to adopt Twisted's *API* is a separate issue, though (see next post). -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
[EMAIL PROTECTED] wrote: > On 08:52 pm, [EMAIL PROTECTED] wrote: > > >When I last looked at twisted (that is several years ago), there were > >several reactors - win32reactor, wxreactor, maybe even more. > > Only the very top-most level decides which reactor the application will use. This is a worry, because it implies that there has to *be* a top level that knows what kind of reactor the whole application will use, and all parts of the application need to know that they will be getting their reactor from that top level. That may not be the case. For example, you want to incorporate some piece of event-driven code written by someone else into your gtk application. But it wasn't written with gtk in mind, so it doesn't know to use a gtkreactor, or how to get a reactor that it can use from your application. This is not my idea of what another poster called a "one-stop shop" -- a common API that different pieces of code can call independently without having to know about each other. To my mind, there shouldn't be a "reactor" object exposed to the application at all. There should just be functions for setting up callbacks. The choice of implementation should be made somewhere deep inside the library, based on what platform is being used. So at this point I'm skeptical that the Twisted API for these things should be adopted as-is. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
[EMAIL PROTECTED] wrote: > sounded like > monkeypatching the socket and asyncore modules to provide asynchronous > file I/O based on the platform-specific IOCP API for Windows. I don't think anyone's suggesting that any long-term solution to all this would involve monkeypatching. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
Oleg Broytmann wrote: > On Wed, Feb 14, 2007 at 03:24:30PM +, Steve Holden wrote: >> Oleg Broytmann wrote: >>> On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote: Python further away from the "Computer Programming for Everyone" arena and closer to the "Systems Programming for Clever Individuals" camp. >>>That's because Python is being developed by "Clever Individuals" and not >>> by "Computer Programming for Everyone Committee". >>> >> I agree that the developers are Clever Individuals. So clever, in fact, >> that they realise Python needs to be as approachable as possible, not a >> language for them alone. > >Anyway I don't believe it's possible to create a CP4E language without a > "CP4E Steering Committee", and I think such committee it Python land is... > dormant at present... > Given that they say "a camel is a horse designed by a committee" I think that language design by committee is very unlikely to produce something well suited to the needs of unsophisticated users. That would require a single individual with good language design skills and the ability to veto features that were out of line with the design requirements. A lot like a BDFL, really. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Greg Ewing wrote: > [EMAIL PROTECTED] wrote: >> On 08:52 pm, [EMAIL PROTECTED] wrote: >> >> >When I last looked at twisted (that is several years ago), there were >> >several reactors - win32reactor, wxreactor, maybe even more. >> >> Only the very top-most level decides which reactor the application will use. > > This is a worry, because it implies that there has to > *be* a top level that knows what kind of reactor the > whole application will use, and all parts of the > application need to know that they will be getting > their reactor from that top level. > > That may not be the case. For example, you want to > incorporate some piece of event-driven code written > by someone else into your gtk application. But it > wasn't written with gtk in mind, so it doesn't know > to use a gtkreactor, or how to get a reactor that it > can use from your application. > If the borrowed code takes a reactor parameter then presumably the top-level code can pass the appropriate reactor type in. If the borrowed code uses a fixed reactor then it's difficult to see how changes to the Twisted API could help. "Incorporating some piece of event-driven code written by someone else" implies specific assumptions about event types and delivery, surely. That's why it's difficult to port code between GUI toolkits, for example, and even more so to write code that runs on several toolkits without change. > This is not my idea of what another poster called a > "one-stop shop" -- a common API that different pieces > of code can call independently without having to know > about each other. > > To my mind, there shouldn't be a "reactor" object > exposed to the application at all. There should just > be functions for setting up callbacks. The choice of > implementation should be made somewhere deep inside > the library, based on what platform is being used. > You seem to be arguing for libraries that contain platform dependencies to handle multiple platforms. Glyph seems to prefer the ability for the library caller to pass in handlers for platform-dependent features. > So at this point I'm skeptical that the Twisted > API for these things should be adopted as-is. > Since Glyph has already stated his opinion that Twisted isn't yet ready for adoption as-is this doesn't add to the discussion. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
Martin v. Löwis wrote:
> switch(o) {
> case And:
> Py_INCREF(And_singleton);
> return And_singleton;
> case Or:
> Py_INCREF(Or_singleton);
> return Or_singleton;
Well, And_singleton and Or_singleton could be anything,
including integers or interned strings. Creating a
class and then a singleton instance for each one seems
like overkill and unnecessary bloat to me.
--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary: rejection of 'dynamic attribute' syntax
Steve Holden wrote: > A further data point is that modern machines seem to give timing > variabilities due to CPU temperature variations even if you always eat > exactly the same thing. Oh, great. Now we're going to have to run our benchmarks in a temperature-controlled oven... -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nb_inplace_power ternary?
Martin v. Löwis wrote: > I think this would violate the policy that a mutating function shouldn't > give the object being modified as the result Well, it's a necessary violation, given the way the inplace methods work. And it doesn't *necessarily* return the same value, it might return a new object. So the return value conveys useful information, unlike with list.sort() et al. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary: rejection of 'dynamic attribute' syntax
On 2/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > What I was trying to say there is that the proposal of new ideas should not > begin with "Hey, I think this might be 'good'" - that's too ill defined. It > should be, "I noticed (myself/my users/my students/other open source > projects) writing lots of code that looks like *this*, and I think it would > be a real savings if it could look like *that*, instead". Yup. > Some > back-of-the-envelope math might be nice, in terms of savings of lines of > code, or an explanation of the new functionality that might be enabled by a > feature. Well, savings in lines of code per se aren't high on my list; savings in conceptual difficulty understanding the code is. Sometimes savings in writing (if they don't go against the savings in understanding) are also important; especially avoiding distractions like having to stop working on the current algorithm in order to figure out how to best write some simple bookkeeping code, etc. (You seem to agree to some extent later, but I think it's worth mentioning my own standards here. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
Josiah Carlson wrote: > Assuming that dictionaries and the hash algorithm for strings is not > hopelessly broken, I believe that one discovers quite quickly when two > strings are not equal. You're probably right, since if there's a hash collision, the colliding strings probably differ in the first char or two. Interning will speed up the case where they are equal, where otherwise you would have to examine every character. Still, there could be extension modules out there somewhere that make use of PyString_CHECK_INTERNED, so there's a slight chance that home-grown interning might not give the same results in all cases. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
Larry Hastings wrote: > If I understand your question correctly, you're saying "why doesn't > string comparison take advantage of interned strings?" No, I understand that it takes advantage of it when the strings are equal. I was wondering about the case where they're not equal. But as has been pointed out, unless you're very unlucky, you find out pretty fast when they're not equal. So I'm happy now. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
At 01:31 PM 2/15/2007 +1300, Greg Ewing wrote: >To my mind, there shouldn't be a "reactor" object >exposed to the application at all. There should just >be functions for setting up callbacks. The choice of >implementation should be made somewhere deep inside >the library, based on what platform is being used. *shudder*. I, on the other hand, prefer to assume that there is no one "top level" and certainly no requirement for a single event loop or reactor. peak.events, for example, lets you have multiple event loops running in the same or different threads. One of these can be Twisted's reactor, if you like, but the framework doesn't impose this singleton-ness on you. (IIUC, Twisted uses a singleton for at least two fairly good reasons: ease of programming, and the fact that certain platforms demand it for performance reasons. I just don't happen to agree that this limitation should be applied across *all* platforms. And there are good solutions for context-specific pseudo-singletons to address the API issue, although they might not be as high-performance as Twisted applications might prefer. Everything's a trade-off.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > On 08:52 pm, [EMAIL PROTECTED] wrote: > > >When I last looked at twisted (that is several years ago), there were > >several reactors - win32reactor, wxreactor, maybe even more. > > Only the very top-most level decides which reactor the application will use. This is a worry, because it implies that there has to *be* a top level that knows what kind of reactor the whole application will use, and all parts of the application need to know that they will be getting their reactor from that top level. That may not be the case. For example, you want to incorporate some piece of event-driven code written by someone else into your gtk application. But it wasn't written with gtk in mind, so it doesn't know to use a gtkreactor, or how to get a reactor that it can use from your application. This is not my idea of what another poster called a "one-stop shop" -- a common API that different pieces of code can call independently without having to know about each other. To my mind, there shouldn't be a "reactor" object exposed to the application at all. There should just be functions for setting up callbacks. The choice of implementation should be made somewhere deep inside the library, based on what platform is being used. Eh, your own example seems to argue the opposite. If the choice for reactor was made somewhere deep inside the library, how does it know to use the GTK reactor? Only the code using GTK knows that it's going to need the GTK reactor. The generic code just uses whatever reactor was selected, automatically. The reason the decision should be made at the topmost level is that this is the most visible and adaptive location. A library or framework has to handle a boundless number of variations of environment, use and co-operation with other libraries and frameworks, whereas the topmost script knows exactly what it wants to do. A library that uses PyGTK can say 'I need the GTK reactor', but it would be wrong. All it needs is a reactor that interacts nicely with GTK. If there are multiple reactors that integrate nicely with GTK, there is no reason for the library to insist on one particular implementation. And it could be in the way, if a second library needs a different kind of integration and it knows of a reactor that supports both that *and* GTK integration. And if the whole system breaks, for some reason, the first place the programmer will look is in his own code, not deep inside another library. For what it's worth, I think a single event-handling mainloop API in the standard library is a *great* idea. Using part of Twisted for it (suitably adapted) is an even greater idea: a whole lot of work and brainpower went into Twisted's core, and it wasn't wasted. Duplicating the effort would be a big mistake and a terrible waste. A from-scratch implementation of an event-handling mechanism will not solve any of the "issues" most people have with Twisted. It will have many more bugs than Twisted (all the ones Twisted had and fixed, sometimes very obscure and hard-to-find bugs), it will not be significantly less complex (Twisted is as complex as it is because it had to be, to do what it is supposed to do) and it will not require any less of a brain-warp to understand (because that's just what event-driven programming takes.) If I wasn't short on free time (spending most of it on Py3k and, soon, py3k-forward-compatibility) I would do all the necessary Twisted-integration work myself :-) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On 12:31 am, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED] wrote: >> On 08:52 pm, [EMAIL PROTECTED] wrote: >> >> >When I last looked at twisted (that is several years ago), there were >> >several reactors - win32reactor, wxreactor, maybe even more. >> >> Only the very top-most level decides which reactor the application will use. > >This is a worry, because it implies that there has to >*be* a top level that knows what kind of reactor the >whole application will use, and all parts of the >application need to know that they will be getting >their reactor from that top level. The default reactor is the most portable one, 'select', and if no other reactor is installed, that's the one that will be used. >That may not be the case. For example, you want to >incorporate some piece of event-driven code written >by someone else into your gtk application. But it >wasn't written with gtk in mind, so it doesn't know >to use a gtkreactor, or how to get a reactor that it >can use from your application. "from twisted.internet import reactor" is the way you get at the reactor, regardless of which one is currently installed. There can only be one reactor active at any given time, because at the very bottom of the event-handling machinery _some_ platform multiplexing API must be called, and that is mostly what the reactor represents. The GTK reactor does not have its own API. It simply allows you to use GTK APIs as well, by back-ending to the glib mainloop. That is, in fact, the whole point of having a "reactor" API in the first place. >This is not my idea of what another poster called a >"one-stop shop" -- a common API that different pieces >of code can call independently without having to know >about each other. >To my mind, there shouldn't be a "reactor" object >exposed to the application at all. There should just >be functions for setting up callbacks. That's what the Twisted "reactor" object *is*, exactly. Functions (well, methods) for setting up callbacks. >The choice of >implementation should be made somewhere deep inside >the library, based on what platform is being used. The "deep inside the library" decision is actually a policy decision made by a server's administrator, or dependent upon the GUI library being used if you need to interact with a GUI event loop. Perhaps the default selection could be better, but installing a reactor is literally one line of code, or a single command-line option to the "twistd" daemon. See: http://twistedmatrix.com/projects/core/documentation/howto/choosing-reactor.html It is completely transparent to the application, _unless_ the application wants to make use of platform-specific features. See the following for more information: http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf although technically Twisted's "reactor" is more like the slightly higher level POSA "proactor" pattern; asyncore is more like a true "reactor" in the sense discussed in that paper. Twisted exposes various APIs for "setting up callbacks" exactly as you describe: http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorTCP.html http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorTime.html >So at this point I'm skeptical that the Twisted >API for these things should be adopted as-is Given that your supporting arguments were almost exactly the opposite of the truth in every case, I think this conclusion should be re-examined :). If you're interested in how a normal Twisted application looks, see this tutorial: http://twistedmatrix.com/projects/core/documentation/howto/servers.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Steve Holden wrote: > If the borrowed code takes a reactor parameter then presumably the > top-level code can pass the appropriate reactor type in. Since there should only be one reactor at a time in any given application, it shouldn't have to be passed in -- it could be held in a global variable deep inside the library. Only the code which creates the reactor initially needs to know about that variable, or even that there is such a thing as a reactor. > "Incorporating some piece of event-driven code written by someone else" > implies specific assumptions about event types and delivery, surely. It requires agreement on how to specify the event types and what to do in response, but that's all it should require. The way I envisage it, setting up an event callback should be like opening a file -- there's only one way to do it, and you don't have to worry about what the rest of the application is doing. You don't have to get passed an object that knows how to open files -- it's a fundamental service provided by the system. You just use it. > That's why it's difficult to port code between GUI toolkits, for > example, and even more so to write code that runs on several toolkits > without change. Just in case it's not clear, the events I'm talking about are things like file and socket I/O, not GUI events. Trying to use two different GUIs at once is not something I'm addressing. Rather, you should be able to write code that does e.g. some async socket I/O, and embed it in a GUI app using e.g. gtk, without having to modify it to take account of the fact that it's working in a gtk environment, or having to parameterise it to allow for such things. > You seem to be arguing for libraries that contain platform dependencies > to handle multiple platforms. I'm arguing that as much of the platform dependency as possible should be in the asyncore library (or whatever replaces it). The main application code *might* have to give it a hint such as "this app uses gtk", but no more than that. And ideally, I'd prefer it not to even have to do that -- pygtk should do whatever is necessary to hook itself into asyncore if at all possible, not the other way around. > Since Glyph has already stated his opinion that Twisted isn't yet ready > for adoption as-is this doesn't add to the discussion. Okay, but one of the suggestions made seemed to be "why not just use the Twisted API". I'm putting forward a possible reason. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Thomas Wouters wrote: > If the choice for > reactor was made somewhere deep inside the library, how does it know to > use the GTK reactor? In my ideal world, there wouldn't actually be a gtk reactor -- there would only be a Linux reactor, a MacOSX reactor, a Windows reactor, etc. Things like pygtk would be adapted to hook into the platform's standard reactor. Less ideal would be for pygtk to intall a gtk reactor when it gets imported. The danger with this approach is that two libraries could fight over which kind of reactor to use. You suggest that the top level could choose some other reactor that is compatible with both libraries. That seems like a rather hit-and-miss approach -- such a reactor might exist, or it might not. If not, you're out of luck. And the chance of finding a suitable reactor gets smaller as the number of libraries increases. > The reason the decision should be made at the topmost level is that this > is the most visible and adaptive location. This is where my vision is fundamentally different: you shouldn't have to *make* a decision in the first place. All event-driven libraries should be made to use the same substrate on any given platform. Then they can coexist without the need for any top-level choices. I know that will be hard to do, but it's the only way out of this mess that I can see. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote: I know that will be hard to do, but it's the only way out of this mess that I can see. That depends on what you consider messy about it. *I* don't like the idea of something in the Python installation deciding which reactor to use. It's my application, and I'm damn well going to tell it what to do. If that means it doesn't work as I expected, it's my own fault :-) In any case, your idea requires a lot of changes in external, non-Python code -- PyGTK simply exposes the GTK mainloop, which couldn't care less about Python's idea of a perfect event reactor model. While those issues are being settled, we'll have to cope with selecting the right reactor manually. It's not all that different from what you want, in any case. The PerfectReactor can be added later, all current reactors aliased to it, and no one would have to change a single line of code. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Phillip J. Eby wrote: > peak.events, for example, lets you have multiple event loops > running in the same or different threads. Different threads is okay if you're willing to use threads, but you might not. The reason you're using an event loop may well be precisely so that you *don't* have to use threads. And... how do you run multiple event loops simultaneously in the *same* thread? That sounds self-contradictory to me. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote: Phillip J. Eby wrote: > peak.events, for example, lets you have multiple event loops > running in the same or different threads. Different threads is okay if you're willing to use threads, but you might not. The reason you're using an event loop may well be precisely so that you *don't* have to use threads. And... how do you run multiple event loops simultaneously in the *same* thread? That sounds self-contradictory to me. If all (or all-but-one) of them have a 'run one iteration' method, you can call that from the 'main' mainloop. Or you can design all mainloops as coroutines and have them call each other. (I haven't looked at Phillip's approach at all, but something tells me coroutines are involved :-) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On Thu, 15 Feb 2007 15:47:39 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote: >Steve Holden wrote: > >> If the borrowed code takes a reactor parameter then presumably the >> top-level code can pass the appropriate reactor type in. > >Since there should only be one reactor at a time in >any given application, it shouldn't have to be passed >in -- it could be held in a global variable deep >inside the library. Only the code which creates the >reactor initially needs to know about that variable, >or even that there is such a thing as a reactor. Whether or not the premise here is accurate may be out of scope for this thread. Or it may not be. I dunno. However, I do want to point out that it is not necessarily correct that there should be only one reactor at a time in a given application. PJE has already explained that peak.events can have multiple reactors. Twisted is tied to one, but this may not always be the case. Whether there is a default reactor for applications that don't care about the ability to have more than one at a time is yet another question which may be worth examining. These are the kinds of things which should be spelled out in a PEP, including the rationale for any particular policy decisions (which should be kept to an absolute minimum) are made. > >> "Incorporating some piece of event-driven code written by someone else" >> implies specific assumptions about event types and delivery, surely. > >It requires agreement on how to specify the event types >and what to do in response, but that's all it should >require. > >The way I envisage it, setting up an event callback >should be like opening a file -- there's only one way >to do it, and you don't have to worry about what the >rest of the application is doing. You don't have to >get passed an object that knows how to open files -- >it's a fundamental service provided by the system. >You just use it. If we suppose that files and sockets are supported in roughly the same way, and we suppose that sockets are supported in the way that Twisted supports them, then there is no difficulty supporting files in this way. :) > >> That's why it's difficult to port code between GUI toolkits, for >> example, and even more so to write code that runs on several toolkits >> without change. > >Just in case it's not clear, the events I'm talking >about are things like file and socket I/O, not GUI >events. Trying to use two different GUIs at once is >not something I'm addressing. Alright, good. Getting two different GUI libraries to play together is a pretty hairy task indeed, and well worth keeping separate from this one. :) > >Rather, you should be able to write code that does >e.g. some async socket I/O, and embed it in a GUI >app using e.g. gtk, without having to modify it to >take account of the fact that it's working in a >gtk environment, or having to parameterise it to >allow for such things. Excellent. To be clear, this is how the Twisted model works, with respect to integration with GUI toolkits. I would not enjoy working with a system in which this was not the case. > >> You seem to be arguing for libraries that contain platform dependencies >> to handle multiple platforms. > >I'm arguing that as much of the platform dependency >as possible should be in the asyncore library (or >whatever replaces it). Certainly. Library code doesn't care if the event loop is driven by select or poll or epoll or /dev/poll or kqueue or aio or iocp or win32 events or realtime signals or kaio or whatever gnarly thing is hidden in gtk or whatever gnarly thing is hidden inside qt or whatever gnarly thing is hidden inside COM or whatever gnarly thing is hidden inside wxWidgets. It cares about what features are available. It requests them somehow, and uses them. If they are unavailable, then it can decide whether the lack is catastrophic and give up or if it can be worked around somehow. The way a Twisted application does this is based on interfaces. Assuming interfaces continue to not be present in the stdlib, a stdlib event loop would have to find some other API for presenting this information, but it is not a very hard problem to solve. >The main application code >*might* have to give it a hint such as "this app >uses gtk", but no more than that. And ideally, I'd >prefer it not to even have to do that -- pygtk >should do whatever is necessary to hook itself >into asyncore if at all possible, not the other >way around. There is some advantage to declaring things up front, lest you get into the situation where you are partway through using code which will suddenly begin to demand Gtk at the same time as you are partway through using code which will suddenly begin to demand Qt, at which point you are in trouble. But this is another minor point. > >> Since Glyph has already stated his opinion that Twisted isn't yet ready >> for adoption as-is this doesn't add to the discussion. > >Okay, but one of the suggestions made seemed to be >"why not just use the Tw
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On Thu, 15 Feb 2007 16:18:40 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote: > [snip] > >This is where my vision is fundamentally different: >you shouldn't have to *make* a decision in the first >place. All event-driven libraries should be made to >use the same substrate on any given platform. Then >they can coexist without the need for any top-level >choices. > >I know that will be hard to do, but it's the only >way out of this mess that I can see. > Thomas already pointed this out, but I'm repeating it anyway. This vision represents an impossible reality at present. You will not get Gtk or Qt or wxWidgets to use Python's event notification API. If you are really very interested in solving this problem, go to the developers of each platform those toolkits run on and sell them on a unified event notification API. Once they have adopted, implemented, and deployed it, you can go to the Gtk, Qt, and wxWidgets teams and tell them to port all of their code to that new API. Then, you can have a unified model in Python. Until then, the practical compromise with almost zero negative consequences (sometimes, one extra piece of configuration will be required - compare this to how the logging module works ;) is to optionally allow explicit reactor selection. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
Greg Ewing <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > > Assuming that dictionaries and the hash algorithm for strings is not > > hopelessly broken, I believe that one discovers quite quickly when two > > strings are not equal. > > You're probably right, since if there's a hash collision, > the colliding strings probably differ in the first char > or two. > > Interning will speed up the case where they are equal, > where otherwise you would have to examine every character. Except that the scanning of the data needs to happen at some point anyways. You first allocate the new string, copy the data into it, compare the content against something in the interned dictionary, and if there is a match, deallocate the new object and return the interned object, otherwise return the new object. This is also the case when one uses the "just give me a string, I'll fill in the data myself" for more or less user-implemented things like ''.join(lst). > Still, there could be extension modules out there > somewhere that make use of PyString_CHECK_INTERNED, > so there's a slight chance that home-grown interning > might not give the same results in all cases. Perhaps. I just never intern. I've found that I'm much happier assuming that the Python runtime will do good enough. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
At 04:25 PM 2/15/2007 +1300, Greg Ewing wrote: >Phillip J. Eby wrote: >>peak.events, for example, lets you have multiple event loops running in >>the same or different threads. > >Different threads is okay if you're willing to use threads, >but you might not. The reason you're using an event loop >may well be precisely so that you *don't* have to use >threads. > >And... how do you run multiple event loops simultaneously >in the *same* thread? When one is nested inside the other. This isn't a common need, but it's occasionally useful if you need to switch back and forth between blocking and non-blocking code. For example, suppose that you have some code that wants to offer a synchronous interface to an asynchronous library... and the synchronous code is being called from a FastCGI "accept" event loop. The inner code can't use the outer event loop, because the outer loop isn't going to proceed until the inner code is finished. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
On 2/14/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Collin Winter schrieb:
> > 2) It turned out that {BinOp, BoolOp,AugAssign,etc}.op were already
> > singleton instances of their respective classes. I've changed
> > asdl_c.py to no longer emit the *_singleton names and to use the
> > corresponding *_type types in their place, which will enable me to
> > write "node.op is _ast.Add", etc.
>
> I don't really like this - it's inconsistent. I'd rather prefer
> if the singletons where exposed under a name, e.g.
> _ast.Add.singleton, or _ast.add (if that doesn't cause conflicts).
What's inconsistent about it? That classes are being used for the
_ast.{Add,Sub,Mult,etc} names?
I don't see the need for both _ast.Add and _ast.Add.singleton or
_ast.add or however else it might be spelled. I'd be perfectly happy
doing something like "_ast.Add = object()" (when initializing the _ast
module), so long as I can write "node.op is _ast.Add", "node.op ==
_ast.Add", or something equally brief and to-the-point.
Collin Winter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] microthreading vs. async io
I've steered clear of this conversation for a while, because it drifted a little bit off my original topic. But I did want to straighten a little bit of terminology out, if only to resolve some of my own confusion over all the hubbub. I don't pretend to define the words others use; these definitions are mine, and apply to what I write below. cooperative multitasking: Dynamically executing multiple tasks in a single thread; comes in two varieties: continuations: Breaking tasks into discrete "chunks", and passing references those chunks around as a means of scheduling. microtreading: Exploiting language features to use cooperative multitasking in tasks that "read" like they are single-threaded. asynchronous IO: Performing IO to/from an application in such a way that the application does not wait for any IO operations to complete, but rather polls for or is notified of the readiness of any IO operations. Twisted is, by the above definitions, a continuation-based cooperative multitasking library that includes extensive support for asynchronous IO, all the way up the network stack for an impressive array of protocols. It does not itself implement microthreading, but Phillip provided a nice implementation of such on top of Twisted[1]. Asyncore *only* implements asynchronous IO -- any "tasks" performed in its context are the direct result of an IO operation, so it's hard to say it implements cooperative multitasking (and Josiah can correct me if I'm wrong, but I don't think it intends to). Much of the discussion here has been about creating a single, unified asynchronous IO mechanism that would support *any* kind of cooperative multitasking library. I have opinions on this ($0.02 each, bulk discounts available), but I'll keep them to myself for now. Instead, I would like to concentrate on producing a small, clean, consistent, generator-based microthreading library. I've seen several such libraries (including the one in PEP 342, which is fairly skeletal), and they all work *almost* the same way, but differ in, for example, the kinds of values that can be yielded, their handling of nested calls, and the names for the various "special" values one can yield. That similar mouldes are being written repeatedly, and presumably applications and frameworks are being built on top of those modules, seems to me to suggest a new "standard" implementation should be added to the standard library. I realize that I'm all talk and no code -- I've been busy, but I hope to rectify the imbalance tonight. Dustin [1] http://mail.python.org/pipermail/python-dev/2007-February/071076.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Thomas Wouters wrote: > If all (or all-but-one) of them have a 'run one iteration' method, you > can call that from the 'main' mainloop. But without some way of blocking until an event arrives for *either* loop, you have to resort to some kind of busy polling, which is not elegant. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Thomas Wouters wrote: > *I* don't like the idea of something in the Python installation > deciding which reactor to use. I wouldn't mind if some way were provided of changing the reactor if you want. I'd just like to see a long term goal of making it unnecessary as far as possible. > In any case, your idea requires a lot of changes in external, non-Python > code -- PyGTK simply exposes the GTK mainloop, which couldn't care less > about Python's idea of a perfect event reactor model. On unix at least, I don't think it should be necessary to change gtk, only pygtk. If it can find out the file descriptor of the connection to the X server, it can plug that into the reactor, and then call gtk_main_iteration_do() whenever something comes in on it. A similar strategy ought to work for any X11-based toolkit that exposes a function to perform one iteration of its main loop. Mileage on other platforms may vary. > The PerfectReactor can be added later, all current reactors > aliased to it, and no one would have to change a single line > of code. Sure. The other side to all this is the client side, i.e. the code that installs event callbacks. At the moment there's no clear direction to take, so everyone makes their own choice -- some use asyncore, some use Twisted, some use the gtk event loop, some roll their own, etc. If it were made known that asyncore or some other thing in the stdlib was intended to become the standard, then it would give people some guidance as to how to write future event-driven code. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Phillip J. Eby wrote: > At 04:25 PM 2/15/2007 +1300, Greg Ewing wrote: >> Phillip J. Eby wrote: >>> peak.events, for example, lets you have multiple event loops running in >>> the same or different threads. >> Different threads is okay if you're willing to use threads, >> but you might not. The reason you're using an event loop >> may well be precisely so that you *don't* have to use >> threads. >> >> And... how do you run multiple event loops simultaneously >> in the *same* thread? > > When one is nested inside the other. This isn't a common need, but it's > occasionally useful if you need to switch back and forth between blocking > and non-blocking code. For example, suppose that you have some code that > wants to offer a synchronous interface to an asynchronous library... and > the synchronous code is being called from a FastCGI "accept" event > loop. The inner code can't use the outer event loop, because the outer > loop isn't going to proceed until the inner code is finished. I actually have some code that works a little bit like this. I have a SelectLoop class that the application knows about and explicitly attaches transport objects to, and queues events on the loop. I have two ways to perform some actions in a "blocking" way. 1) I can create a new SelectLoop and move some transports temporarily from the main loop to the temporary loop to ignore all other events for a while. 2) I can re-enter the SelectLoop run() method and keep reacting to all events. Once the right event occurs - I exit from the nested run() and continue on. This does require a lot more mental effort though. Note that my code is nowhere near as ambitious as Twisted, but I watned to have the above flexibility. The code really only has to work on AIX and Linux, and in a limited way, Windows. - Dave ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
On 2/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > When one is nested inside the other. This isn't a common need, but it's > occasionally useful if you need to switch back and forth between blocking > and non-blocking code. For example, suppose that you have some code that > wants to offer a synchronous interface to an asynchronous library... and > the synchronous code is being called from a FastCGI "accept" event > loop. The inner code can't use the outer event loop, because the outer > loop isn't going to proceed until the inner code is finished. This would also let you wrap sys.stdout.write() in a nested event loop so as to allow print statements to still work while you use have it set to non-blocking mode, but I could see it argued that using print statements at all is wrong at that point. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
Collin Winter schrieb:
> What's inconsistent about it? That classes are being used for the
> _ast.{Add,Sub,Mult,etc} names?
Exactly. These aren't names - they are nodes in the tree. All nodes
are instances of _ast.AST.
> I don't see the need for both _ast.Add and _ast.Add.singleton or
> _ast.add or however else it might be spelled. I'd be perfectly happy
> doing something like "_ast.Add = object()" (when initializing the _ast
> module), so long as I can write "node.op is _ast.Add", "node.op ==
> _ast.Add", or something equally brief and to-the-point.
Would you like to do the same for Pass, Break, Continue, and Ellipsis?
They are also "just names". If you make _ast.Add the entry in the
tree itself, why not _ast.Break? Or, if you have a way to deal with
_ast.Break, why can't the same way work for _ast.Add?
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Thomas Wouters schrieb: > If all (or all-but-one) of them have a 'run one iteration' method, you > can call that from the 'main' mainloop. That doesn't really work (and neither do variations involving coroutines. Either the 'run one iteration' method blocks until one even arrives, in which case it may block for a long time while other loops have events pending (which then won't get processed). Or each 'run one iteration' method has a polling mode (e.g. with a time-out), in which case you get busy wait (you can fiddle with the time-out value to trade business vs. responsiveness). The 'run one iteration' approach doesn't support writing applications that are single-threaded, responsive, and idle when there is nothing to do. I can't believe that coroutines help in any way here. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
Greg Ewing schrieb: > On unix at least, I don't think it should be necessary > to change gtk, only pygtk. If it can find out the file > descriptor of the connection to the X server, it can > plug that into the reactor, and then call > gtk_main_iteration_do() whenever something comes in > on it. That is insufficient. The gtk main loop has more input sources than just the connection to X: - timers can be registered, which are called when the time comes - idle handlers can be registered which are called when there are no other events - child handlers are invoked when a child process terminates - additional file descriptors can be registered (probably used for sockets primarily) - a generalzed 'event source' can be hooked into it, with C functions for prepare, check, dispatch, and finalize See http://www.gtk.org/api/2.6/glib/glib-The-Main-Event-Loop.html Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] microthreading vs. async io
[EMAIL PROTECTED] schrieb: > Asyncore *only* implements asynchronous IO -- any "tasks" performed in > its context are the direct result of an IO operation, so it's hard to > say it implements cooperative multitasking (and Josiah can correct me if > I'm wrong, but I don't think it intends to). I'm trying to correct you: By your definition, asyncore implements cooperative multi-tasking. You didn't define 'task', but I understand it as 'separate activity'. With asyncore, you can, for example, run a web server and an IRC server in a single thread, as separate tasks, and asyncore deals with the scheduling between these tasks. In your terminology, it is based on continuations: the chunk you specify is the event handler. Indeed, asyncore's doc string starts with # There are only two ways to have a program on a single # processor do "more than one thing at a time". and goes on suggesting that asyncore provides one of them. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
