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 strin
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 ha
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
> writ
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)
{
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>^
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 a
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 se
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
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 Indivi
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
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
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" ca
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
>>> u
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
wa
* 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 wit
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
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
h
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
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
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 interp
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
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
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
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 pl
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
[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.
>
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 comp
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
e
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
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
in
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
[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
[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
__
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 f
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 applicat
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;
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
___
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 obje
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) wr
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 fir
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
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
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
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
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 variabl
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
py
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
app
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 u
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
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 applic
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
>t
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 col
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
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
> > corres
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 definiti
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
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 ca
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 re
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
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
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
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.
Th
[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
63 matches
Mail list logo
