Guido van Rossum wrote:
> On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>
>>So modeling the switch after dictionary dispatching more directly where
>>the switch is explicitly defined first and then used later might be good
>>both because it offers reuse in the current scope and it can easily be
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Bad Case Option (5) -- ad hoc mixture
> -
>
> Pick an arbitrary set of rules, and follow it.
>
> Guido is currently leaning towards this, with the rules being "freeze
> at definition", raise for unhashable, igno
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> > (5) I think file creation/writing should be capped rather than
> > binary; it is reasonable to say "You can create a single temp file up
> > to 4K" or "You can create files, but not more than 20Meg total".
>
> That has been suggested before
On Tue, 27 Jun 2006, Jim Jewett wrote:
> (Almost) everyone agrees that the case expressions SHOULD be run-time
> constants. The disagreements are largely over what to do when this
> gets violated.
I like your summary and understood most of it (options 1, 2, 3, 5, 6).
The only part i didn't unders
Alexander Belopolsky wrote:
> Setobject code allocates several internal objects on the heap that are
> cleaned up by the PySet_Fini function. This is a fine design choice,
> but it often makes debugging applications with embedded python more
> difficult.
given that CPython has about a dozen Fini
> The plan is to allow pure Python code to be embedded into web pages like
> JavaScript. I am not going for the applet approach like Java.
Java support is now just a plug-in. Should be easy to make a Python
plug-in system that works the same way. If only we had a GUI... :-)
Bill
__
On 6/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
>
> > This is where I wonder why the "def __main__()" PEP was rejected in the
> > first place. It would have solved this problem as well.
>
> Could this be reconsidered for Py3k?
You have a point.
--
--Guido van Rossum (hom
At 12:02 PM 6/28/2006 +1200, Greg Ewing wrote:
>Martin v. Löwis wrote:
>
> > Again, I believe this is all included for ExtensionClasses: it looks
> > for __class__ on the object if the type check fails, so that an
> > ExtensionClass could be actually a class derived from the C type.
>
>Now that we
Giovanni Bajo wrote:
> This is where I wonder why the "def __main__()" PEP was rejected in the
> first place. It would have solved this problem as well.
Could this be reconsidered for Py3k?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http
Guido van Rossum wrote:
> Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
> don't want to mess with it.
It would only make a difference for main modules inside
packages. Wouldn't that be fairly rare? The vast majority
of existing __name__ == "__main__" uses ought to be
unaffect
Martin v. Löwis wrote:
> Again, I believe this is all included for ExtensionClasses: it looks
> for __class__ on the object if the type check fails, so that an
> ExtensionClass could be actually a class derived from the C type.
Now that we have had new-style classes for quite a
while, is there st
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 6/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I like Python's rules to be simple, and I
> > prefer to occasionally close off a potential optimization path in the
> > sake of simplicity.
>
> (Almost) everyone agrees that the case expr
Ron Adam wrote:
> In this instance the switch would be redefined 10 times. The ending
> switch would be:
>
> switch S:
>case 10: print 42
Silly mistake correction... :)
switch S:
case 9: print 42
___
Python-Dev mailing
Guido van Rossum wrote:
>> What was intended probably would be more closely related to constructing
>> a switch with BASICS gosub command.
>
> I understand now.
>
> But I have a question: if I write
>
> for i in range(10):
>switch S:
> case i: print 42
>
> (i.e. the switch is *inside
One of the big problems here seems to be that an optimized switch
statement requires some code to be evaluated fewer times than the rest
of the switch statement, and there isn't any good way to make that
happen with a single statement. Thus, I propose two statements: a
'dispatcher' statement and a
> But what's the point? We have until Python 3000 anyway.
Ah, my mistake. In my enthusiasm, I foolishly got the time frames of
peps 3103 & 275 mixed up.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
On 6/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I like Python's rules to be simple, and I
> prefer to occasionally close off a potential optimization path in the
> sake of simplicity.
(Almost) everyone agrees that the case expressions SHOULD be run-time
constants. The disagreements are
On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > It looks like your proposal is to change switch into a command that
> > defines a function of one parameter. Instead of the "do
> > in " call you could just call the switch -- no new syntax
> > needed. Your example above
Guido van Rossum wrote:
> On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I use dict base dispatching in a number of my programs and like it with
>> the exception I need to first define all the code in functions (or use
>> lambda) even if they are only one line. So it results in a three step
>>
Do we need a sort of mini bug-day to look at the outstanding bugs and
note ones that absolutely need to be fixed before 2.5final? Or has
someone already done this?
--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:>> > On 6/27/06, Brett Cannon <
[EMAIL PROTECTED]> wrote:> Shouldn't be as long as you put the call right after variable declarations> and you don'
Setobject code allocates several internal objects on the heap that are
cleaned up by the PySet_Fini function. This is a fine design choice,
but it often makes debugging applications with embedded python more
difficult.
I propose to eliminate the need for PySet_Fini as follows:
1. Make dummy and
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> > On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Shouldn't be as long as you put the call right after variable declarations
> and you don't do an PyObject creation at variable declara
On 6/27/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:>> ...>> Caps and current usage should also be available (though read-only)
>> from python; it is quite sensible to spill some cache when getting too>> close to your mem
Brett Cannon wrote:
> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> ...
>> Caps and current usage should also be available (though read-only)
>> from python; it is quite sensible to spill some cache when getting too
>> close to your memory limit.
>
> Yeah, being able to read your restricti
> On compilation, freeze any cases that meet the School-II conditions
> and have a trustworthy __hash__ method into a dictionary.
As long as the semantics are based on if-elif, you have to support
if(optimizable)
elif (has a side effect)
elif (optimizable)
elif (not optimizabl
On 6/27/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
"Brett Cannon" <[EMAIL PROTECTED]> writes:> If you look at that crasher, you will notice that recursion depth is set> to 1 << 30 before any code is run. If you remove that setting high
> setting and go with the default then the test doesn't cra
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> My worry with this is that by providing checking functions that just return> true or false that people will rely on those too much and have logic errors
> in their check and let security holes dev
Does anyone here have time to look at this?
On 6/26/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
> On 6/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 6/14/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
> > > ... It would be better to change the message
> > > to "'Foo' objec
On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> I use dict base dispatching in a number of my programs and like it with
> the exception I need to first define all the code in functions (or use
> lambda) even if they are only one line. So it results in a three step
> process, define functions, d
"Brett Cannon" <[EMAIL PROTECTED]> writes:
> If you look at that crasher, you will notice that recursion depth is set
> to 1 << 30 before any code is run. If you remove that setting high
> setting and go with the default then the test doesn't crash and raises the
> appropriate RuntimeError.
>
> S
> Given that variant, my reasons for preferring Option 2 over Option 3 are:
> - the semantics are the same at module, class and function level
> - the order of execution roughly matches the order of the source code
> - it does not cause any surprises when switches are inside conditional logic
On 6/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <
[EMAIL PROTECTED]> wrote:
If you look at that crasher, you will notice that recursion depth is set to 1 << 30 before any code is run. If you remove that setting high setting and go with the default then the test does
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> My worry with this is that by providing checking functions that just return
> true or false that people will rely on those too much and have logic errors
> in their check and let security holes develop. That is why the checking
> functions as t
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
If you look at that crasher, you will notice that recursion depth is set to 1 << 30 before any code is run. If you remove that setting high setting and go with the default then the test doesn't crash and raises the appropriate RuntimeError.
Sett
On Tue, Jun 27, 2006, Phillip J. Eby wrote:
> At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote:
>>
>>Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
>>don't want to mess with it.
>
> Actually, maybe we *do* want to, for this usage.
>
> Note that until Python 2.5, it was not
On 6/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote:
> >Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
> >don't want to mess with it.
>
> Actually, maybe we *do* want to, for this usage.
>
> Note that until Python 2.5, it w
On 6/27/06, Nicko van Someren <[EMAIL PROTECTED]> wrote:
> Hum... other than effecting more or less every runnable python module
> around it should be very little impact. That sounds like quite a bit
> of impact to me!
Going from "__name__ == '__main__'" to "__name__.endswith('__main__')"
can be
Phillip J. Eby wrote:
> Actually, maybe we *do* want to, for this usage.
>
> Note that until Python 2.5, it was not possible to do "python -m
> nested.module", so this change merely prevents *existing* modules from
> being run this way -- when they could not have been before!
>
> So, such modules
If you look at that crasher, you will notice that recursion depth is set to 1 << 30 before any code is run. If you remove that setting high setting and go with the default then the test doesn't crash and raises the appropriate RuntimeError.
Setting the recursion depth to such a high number will cr
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:> > (2) For the APIs returning an int, it wasn't clear what that int
> > would be, other than NULL => interpreter is trusted.> Doesn't matter. I
At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote:
>Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
>don't want to mess with it.
Actually, maybe we *do* want to, for this usage.
Note that until Python 2.5, it was not possible to do "python -m
nested.module", so this change m
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > (2) For the APIs returning an int, it wasn't clear what that int
> > would be, other than NULL => interpreter is trusted.
> Doesn't matter. I should probably change it to a say "a false v
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
(1) Is it impossible for an interpreter to switch between trusted anduntrusted modes? This is probably a reasonable restriction, but worthcalling out loudly in the docs.Yes, you should not change the state once the interpreter is used for executio
On 6/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I've written a new PEP, summarizing (my reaction to) the recent
> > discussion on adding a switch statement. While I have my preferences,
> > I'm trying to do various alternatives justice in the descriptions. The
> >
On 27 Jun 2006, at 13:03, Nick Coghlan wrote:
> ...
> It occurred to me that a slight modification to PEP 338 might solve
> the
> problem fairly cleanly: instead of simply setting __name__ to
> '__main__' for a
> module in a package, the -m switch could prepend the package name
> so that
> re
On 6/27/06, Robin Bryce <[EMAIL PROTECTED]> wrote:
> > PEP 3103, When to Freeze the Dispatch Dict/Option 1
>
> 2 things resonated with me for Raymond's proposal and the follow up:
>
> - It seemed agnostic to almost all of the independently contentious issues.
Except for the need to use named const
On 6/26/06, K.S.Sreeram <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I think we need a PEP for const/static/only/cached/precomputed or
> > whatever people like to call it.
>
> fredrik's got a micro pep at http://online.effbot.org
>
> > Once we have (say) static, I think making the case
On 6/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mitch Chapman [1] tripped over the fact that relative imports don't like main
> modules because __name__ doesn't contain any package hierarchy information.
>
> It occurred to me that a slight modification to PEP 338 might solve the
> problem fai
(1) Is it impossible for an interpreter to switch between trusted and
untrusted modes? This is probably a reasonable restriction, but worth
calling out loudly in the docs.
(2) For the APIs returning an int, it wasn't clear what that int
would be, other than NULL => interpreter is trusted.
I'm
At 02:49 PM 6/27/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> >> It seems that the __class__ is only accessed in some cases, but not
> >> always, leading to what I think is a semantic inconsistency.
> >
> > It's not inconsistent - isinstance() checks __class__ in *addition* to
> > t
At 09:29 AM 6/27/2006 +0200, Maric Michaud wrote:
>Le mardi 27 juin 2006 05:38, Phillip J. Eby a écrit :
> > As it happens, this is due to the fact that E is a type, while E() is
> > not. There's an optimization in the isinstance() machinery that simply
> > checks to see if D().__class__ is a subt
At 10:13 PM 6/26/2006 -0700, Guido van Rossum wrote:
>On 6/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>>Phillip J. Eby wrote:
>>
>> > It's not inconsistent - isinstance() checks __class__ in *addition* to
>> > type() in order to allow proxying tricks like lying about your
>> > __class__.
>>
>>If
Guido van Rossum wrote:
> For a real example from C++, read "Double Checked Locking is Broken":
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> (I first heard about this from Scott Meyers at the '06 ACCU conference
> in Oxford; an earlier version of his talk is also onlin
Guido van Rossum wrote:
> I've written a new PEP, summarizing (my reaction to) the recent
> discussion on adding a switch statement. While I have my preferences,
> I'm trying to do various alternatives justice in the descriptions. The
> PEP also introduces some standard terminology that may be help
Martin Maly wrote:
> Thanks for the response. The code snippet I sent deals with new style
> classes only so I assume that in some cases isinstance falls back to
> old-style-like handling which then asks for __bases__ and __class__
> etc, possibly incorrectly so on new style classes.
Again, I beli
Phillip J. Eby wrote:
>> It seems that the __class__ is only accessed in some cases, but not
>> always, leading to what I think is a semantic inconsistency.
>
> It's not inconsistent - isinstance() checks __class__ in *addition* to
> type() in order to allow proxying tricks like lying about you
Mitch Chapman [1] tripped over the fact that relative imports don't like main
modules because __name__ doesn't contain any package hierarchy information.
It occurred to me that a slight modification to PEP 338 might solve the
problem fairly cleanly: instead of simply setting __name__ to '__main_
> PEP 3103, When to Freeze the Dispatch Dict/Option 1
2 things resonated with me for Raymond's proposal and the follow up:
- It seemed agnostic to almost all of the independently contentious issues.
- "is defined tightly enough to allow room for growth and elaboration over
time" [Raymond]. In par
Le mardi 27 juin 2006 05:38, Phillip J. Eby a écrit :
> At 05:16 PM 6/26/2006 -0700, Martin Maly wrote:
> > >>> class D(object):
> >
> >... def getclass(self):
> >... print "D.getclass"
> >... return C
> >... __class__ = property(getclass)
> >...
> >
> > >>> isinstance(D(),
Guido van Rossum wrote:
> I think we need a PEP for const/static/only/cached/precomputed or
> whatever people like to call it.
fredrik's got a micro pep at http://online.effbot.org
> Once we have (say) static, I think making the case expressions static
> by default would still cover all useful ca
Ralf W. Grosse-Kunstleve wrote:
> --- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>
>>I think it is safe to say that Twisted is more widely used than anything
>>Google has yet released. Twisted also has a reasonably plausible
>>technical reason to dislike this change. Google has a bunch of en
62 matches
Mail list logo
