Re: [Python-Dev] Musings on concurrency and scoping ("replacing" Javascript)
Ka-Ping Yee <[EMAIL PROTECTED]> writes: > Client-side web scripting tends to have a callback/continuation-ish > concurrency style because it has to deal with network transactions > (which can stall for long periods of time) in a user interface that > is expected to stay always responsive. The Firefox API is full of > listeners/observers, events, and continuation-like things. So one > thing to consider is that, when Python is used for these purposes, > it may be written in a specialized style. You could even call it a Twisted style :-) Cheers, mwh -- Considering that this thread is completely on-topic in the way only c.l.py threads can be, I think I can say that you should replace "Oblivion" with "Gravity", and increase your Radiohead quotient. -- Ben Wolfson, comp.lang.python ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Missing" 2.5 feature
[Anthony Baxter]
> Hm. Would it be a smaller change to expose head_mutex so that the
> external module could use it?
No, in part because `head_mutex` may not exist (depends on the build
type). What an external module would actually need is 3 new public C
API functions, callable workalikes for pystate.c's internal
HEAD_{INIT, LOCK, UNLOCK} macros. Then the only clear use for those
would be to help implement the proposed new function -- bad tradeoff.
> I'm really not keen on this seeming tide of new features that
> seem to be popping up.
Well, suck it up, cuz that never ends ;-)
> We're only a few days away from the second and final planned beta - it's
> getting _awfully_ late to be slotting in new features.
Yup! OTOH, I'm not proposing to change the behavior of existing code
in any way, just adding a new C function comprising about a dozen
lines of straightforward code (it can be that simple in the core
because it has direct access to the relevant internals then). The
biggest risk I see is that I might screw up the LaTeX -- which is a
risk. There's no realistic chance that this would suffer
platform-specific compiler or runtime problems, or break other code
(it only needs read access to the relevant internals, it never writes
to them).
Of course that doesn't mean you can't say no. It only means you shouldn't :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
> So, if I understand correctly, in the presence of a global statement > search > just goes up the lexical chain looking for the first occurrence of the > variable to modify? > > x = 0 > def f(): > x = 1 > def g(): > global x > x = 2 > print x > g() > print x > f() > print x > > Today it prints > > 2 > 1 > 2 > > You're suggesting it will print > > 2 > 2 > 0 > > ? Sounds right to me. > Sounds reasonable to me. If we're talking py3k I'd chuck "global" as a > keyword though and replace it with something like "outer". I must say that I don't like "outer" any more than I like "global." The problem is that in both cases we are selecting the *inner*most definition that isn't in the current scope. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
On 7/8/06, Talin <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:>> On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]
> wrote:>> > I'd like the answer to be yes. It sounded for a while like this>> > was not part of Brett's plan, though. Now i'm not so sure. It>> > sounds like you're also interested in having the answer be yes?
>> >>> > Let's keep talking about and playing with more examples -- i think>> > they'll help us understand what goals we should aim for and what>> > pitfalls to anticipate before we nail down too many details.
I'd like the answer to be no, because I don't believe that we can>> trust the VM to provide sufficient barriers. The old pre-2.2>> restricted execution mode tried to do this but
2.2 punched a million>> holes in it. Python isn't designed for this (it doesn't even enforce>> private attributes). I guess this is also the main reason I'm>> skeptical about capabilities for Python.
>> My plan is no. As Guido said, getting this right is feasibly> questionable. I do not plan on trying to have security proxies or such> implemented in Python code; it will need to be in C. If someone comes
> along> and manages to find a way to make Python work without significantly> changing> the languages, great, and we can toss out my security implementation for> that.>> But as of right now, I am not planning on making Python code safe to run in
> Python code.It might be possible for the code *outside* the sandbox to create newsecurity policies written in Python.Lets start with the concept of a generic "protection" wrapper - its a C
proxy object which can wrap around any Python object, and which canrestrict access to a specific set of methods. So for example:protected_object = protect(myObject, methods=set('open','close'))
'protect' creates a C proxy which restricts access to the object,allowing only those methods listed to be called.Now, lets create a security policy, written in Python. The policy isessentially a factory which creates wrapped objects:
class MyPolicy: # Ask the policy to create a file object def file( path, perms ): if perms == 'r': # Trivial example, a real proxy would be more # sophisticated, and probably configurable.
return protect( file( path, perms ), methods=set('open', 'read', 'close') ) raise SecurityExceptionNow, when we create our sandbox, we pass in the policy:
sb = Sandbox( MyPolicy() )The sandbox calls 'protect' on the policy object, preventing it frombeing inspected or called inappropriately.Using a factory method callback, one could store the PyCodeObject in a C proxy object that just acts as a complete delegate, forwarding all method calls to the internally stored PyCodeObject. That would work.
For this initial implementation, though, I am not going to try to support this. We can always add support like this later since it doesn't fundamentally break or change anything that is already planned. Let's focus on getting even more basic stuff working before we start to get too fancy.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On Sun, 9 Jul 2006, Andrew Koenig wrote: > > Sounds reasonable to me. If we're talking py3k I'd chuck "global" as a > > keyword though and replace it with something like "outer". > > I must say that I don't like "outer" any more than I like "global." The > problem is that in both cases we are selecting the *inner*most definition > that isn't in the current scope. That's why "nonlocal" is a better choice in my opinion. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 393 open (+15) / 3315 closed (+17) / 3708 total (+32) Bugs: 908 open (+22) / 5975 closed (+49) / 6883 total (+71) RFE : 223 open ( -1) / 229 closed ( +2) / 452 total ( +1) New / Reopened Patches __ test_grp.py doesn't skip special NIS entry, fails (2006-06-22) http://python.org/sf/1510987 opened by Mat Martineau socket.gethostbyaddr fix for machines with incomplete DNS (2006-06-23) http://python.org/sf/1511317 opened by Charles Schwieters Speed up decimal object construction (2006-06-25) CLOSED http://python.org/sf/1511853 opened by Nick Coghlan ast branch changed interactive module name (2006-06-25) http://python.org/sf/1512007 opened by Jp Calderone Improves an error message from setattr (2006-06-26) http://python.org/sf/1512942 opened by Alexander Belopolsky [FIX][Bug 1512695] cPickle.loads seg. faults (2006-06-27) CLOSED http://python.org/sf/1513206 opened by Faik Uygur Remove reduce() (2006-06-27) CLOSED http://python.org/sf/1513249 opened by Collin Winter Clean up usage of map() in the stdlib (2006-06-27) http://python.org/sf/1513299 opened by Collin Winter new turtle module (2006-06-28) http://python.org/sf/1513695 opened by Lingl docs for xturtle.py (2006-06-28) CLOSED http://python.org/sf/1513699 opened by Lingl Move reduce() to functools (2006-06-28) http://python.org/sf/1513870 opened by Collin Winter mailbox (Maildir): avoid losing messages on name clash (2006-06-29) http://python.org/sf/1514543 opened by David Watson mailbox: use fsync() to ensure data is really on disk (2006-06-29) http://python.org/sf/1514544 opened by David Watson proposal for a new circle method (2006-06-29) CLOSED http://python.org/sf/1514737 opened by Lingl 1515163 fix - traceback and str exc (2006-06-30) http://python.org/sf/1515343 opened by Jim Jewett urllib2 redirection fix (2006-07-02) http://python.org/sf/1515745 opened by Petr Gladkikh tarfile.py fix for #1471427 and updates (2006-05-09) http://python.org/sf/1484695 reopened by gustaebel tarfile.py fix for #1471427 and updates (2006-05-09) http://python.org/sf/1484695 reopened by gustaebel Remove deprecated functions from operator (2006-07-03) http://python.org/sf/1516309 opened by Collin Winter Module uuid: reduce pickle footprint (2006-07-03) http://python.org/sf/1516327 opened by Michael Amrhein Module uuid: functions for retrieving MAC addres (2006-07-03) http://python.org/sf/1516330 opened by Michael Amrhein Remove sys.exitfunc (2006-07-03) http://python.org/sf/1516375 opened by Collin Winter OpenVMS patches Modules directory (2006-07-04) http://python.org/sf/1516912 opened by Piéronne Jean-François Fix for Lib/test/crashers/gc_inspection.py (2006-07-04) http://python.org/sf/1517042 opened by Collin Winter Patch to commands.py to enable callback support (2006-07-05) http://python.org/sf/1517586 opened by Brad Doctor Patch for ctypes to enable custom objects in function calls (2006-07-05) http://python.org/sf/1517790 opened by Thomas Heller Patch for bug #1514451 (2006-07-06) http://python.org/sf/1517891 opened by Thomas Lee assert for NULL in Py_INCREF Py_DECREF (2006-07-06) http://python.org/sf/1517947 opened by Rene Dudfield ext/win-cookbook.html has a broken link to distutils (2006-07-07) http://python.org/sf/1518772 opened by Johannes Gijsbers New ver. of 1102879: Fix for 926423: socket timeouts (2006-07-07) http://python.org/sf/1519025 opened by Tony Nelson turtle.py: correcting begin_fill (2006-07-09) http://python.org/sf/1519566 opened by Lingl Patches Closed __ MS Toolkit Compiler no longer available (2006-06-20) http://python.org/sf/1509163 closed by loewis Patch for 1506758 - popen2/subprocess MAXFD MemoryErrors (2006-06-15) http://python.org/sf/1506760 closed by astrand Speed up decimal object construction (2006-06-25) http://python.org/sf/1511853 closed by ncoghlan [FIX][Bug 1512695] cPickle.loads seg. faults (2006-06-27) http://python.org/sf/1513206 closed by gbrandl Remove reduce() (2006-06-27) http://python.org/sf/1513249 closed by collinwinter docs for xturtle.py (2006-06-28) http://python.org/sf/1513699 closed by loewis Make thread stack size runtime tunable (03/20/06) http://python.org/sf/1454481 closed by sf-robot proposal for a new circle method (2006-06-30) http://python.org/sf/1514737 closed by loewis 1515169 fix (ImportWarning flood) (2006-06-30) http://python.org/sf/1515361 closed by nnorwitz Alternative fix for ImportWarning (fix for 1515169) (2006-07-01) http://python.org/sf/1515609 closed by nnorwitz telnetlib timeout fi
[Python-Dev] Unary minus bug
The bug was reported by Armin in SF #1333982:
the literal -2147483648 (i.e. the value of -sys.maxint-1) gives
a long in 2.5, but an int in <= 2.4.
I have a fix but I wonder if it's the right thing to do. I suppose
returning a long has the chance of breaking someone code. Here's
the test we currently have for a related case:
[...]
# 32-bit machine
all_one_bits = '0x'
self.assertEqual(eval(all_one_bits), 4294967295L)
self.assertEqual(eval("-" + all_one_bits), -4294967295L)
I guess I would add self.assertTrue(isinstance(eval("-2147483648"), int))
to that set of tests.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unary minus bug
I think it ought to be an int, like before.
--Guido
On 7/9/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> The bug was reported by Armin in SF #1333982:
>
> the literal -2147483648 (i.e. the value of -sys.maxint-1) gives
> a long in 2.5, but an int in <= 2.4.
>
> I have a fix but I wonder if it's the right thing to do. I suppose
> returning a long has the chance of breaking someone code. Here's
> the test we currently have for a related case:
>
> [...]
> # 32-bit machine
> all_one_bits = '0x'
> self.assertEqual(eval(all_one_bits), 4294967295L)
> self.assertEqual(eval("-" + all_one_bits), -4294967295L)
>
> I guess I would add self.assertTrue(isinstance(eval("-2147483648"), int))
> to that set of tests.
>
> Neil
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unary minus bug
[Neil Schemenauer]
> The bug was reported by Armin in SF #1333982:
>
> the literal -2147483648 (i.e. the value of -sys.maxint-1) gives
> a long in 2.5, but an int in <= 2.4.
That actually depends on how far back you go. It was also a long "at
the start". IIRC, Fred or I added hackery to make it an int, because
back then there was a sharp distinction between int and long and a
surprising number of people complained about this case. Strictly
speaking, -2147483648 is not an integer literal (see the grammar --
Python has only positive integer literals).
> I have a fix but I wonder if it's the right thing to do.
Practicality beats purity here, IMO -- +1.
> I suppose returning a long has the chance of breaking someone code. Here's
> the test we currently have for a related case:
>
> [...]
> # 32-bit machine
> all_one_bits = '0x'
> self.assertEqual(eval(all_one_bits), 4294967295L)
> self.assertEqual(eval("-" + all_one_bits), -4294967295L)
>
> I guess I would add self.assertTrue(isinstance(eval("-2147483648"), int))
> to that set of tests.
Or, more obscure but maybe better (since this also tests the similar
endcase on sizeof(long) == 8 boxes):
minint = -sys.maxint-1
self.assert_(isinstance(minint, int))
self.assert_(isinstance(eval(str(minint)), int))
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unary minus bug
Do we care about this (after your checkin and with my fix to make
32-63 bit values ints rather than longs):
# 64 bit box
>>> minint = str(-sys.maxint - 1)
>>> minint
'-9223372036854775808'
>>> eval(minint)
-9223372036854775808
>>> eval('-(%s)' % minint[1:])
-9223372036854775808L
n
--
On 7/9/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> The bug was reported by Armin in SF #1333982:
>
> the literal -2147483648 (i.e. the value of -sys.maxint-1) gives
> a long in 2.5, but an int in <= 2.4.
>
> I have a fix but I wonder if it's the right thing to do. I suppose
> returning a long has the chance of breaking someone code. Here's
> the test we currently have for a related case:
>
> [...]
> # 32-bit machine
> all_one_bits = '0x'
> self.assertEqual(eval(all_one_bits), 4294967295L)
> self.assertEqual(eval("-" + all_one_bits), -4294967295L)
>
> I guess I would add self.assertTrue(isinstance(eval("-2147483648"), int))
> to that set of tests.
>
> Neil
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unary minus bug
On Sun, Jul 09, 2006 at 03:02:06PM -0700, Neal Norwitz wrote:
> Do we care about this (after your checkin and with my fix to make
> 32-63 bit values ints rather than longs):
>
> # 64 bit box
> >>>minint = str(-sys.maxint - 1)
> >>>minint
> '-9223372036854775808'
> >>>eval(minint)
> -9223372036854775808
> >>>eval('-(%s)' % minint[1:])
> -9223372036854775808L
I don't think we care. Python <= 2.4 has the same behavior (i.e.
adding parens defeats the constant folding since it's done at the
syntax tree level).
Where's your fix regarding 32-63 bit ints? I'm not familiar with
that issue but my recent check-in appears to have broke the 64-bit
buildbots. If no one can explain what's going on there then I guess
I will have to find a login on a 64-bit machine at debug it myself.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unary minus bug
On 7/9/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 09, 2006 at 03:02:06PM -0700, Neal Norwitz wrote:
> > Do we care about this (after your checkin and with my fix to make
> > 32-63 bit values ints rather than longs):
> >
> > # 64 bit box
> > >>>minint = str(-sys.maxint - 1)
> > >>>minint
> > '-9223372036854775808'
> > >>>eval(minint)
> > -9223372036854775808
> > >>>eval('-(%s)' % minint[1:])
> > -9223372036854775808L
>
> I don't think we care. Python <= 2.4 has the same behavior (i.e.
> adding parens defeats the constant folding since it's done at the
> syntax tree level).
Ok, unless someone care's enough to make a patch, I'm removing this
from the outstanding issues for 2.5.
> Where's your fix regarding 32-63 bit ints? I'm not familiar with
I just had to finish the test. It's checked in now and should fix the
buildbot problems. Your test exposed the issue, but didn't cause it.
It was caused
by the optimization of converting strings to ints. My approach to fix it was
kinda hacky (just add the proper table for 64-bit machines). I guess
ideally we would generate this table based off sizeof(long). Probably
should have added
a TODO.
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Missing" 2.5 feature
Just to make life harder ;-), I should note that code, docs and tests for sys._current_frames() are done, on the tim-current_frames branch. All tests pass, and there are no leaks in the new code. It's just a NEWS blurb away from being just another hectic release memory :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Ka-Ping Yee wrote: > On Sun, 9 Jul 2006, Andrew Koenig wrote: > >>>Sounds reasonable to me. If we're talking py3k I'd chuck "global" as a >>>keyword though and replace it with something like "outer". >> >>I must say that I don't like "outer" any more than I like "global." The >>problem is that in both cases we are selecting the *inner*most definition >>that isn't in the current scope. > > > That's why "nonlocal" is a better choice in my opinion. Some alternatives: use x using x with x -- recycle a keyword? reuse x use extant x share x common x same x borrow x existing x Although, to be perfectly honest, the longer this discussion goes on, the more that I find that I'm not buying Guido's argument about it being better to define this at the point of use rather than at the point of definition. I agree with him that "point of use" is more Pythonic, but I'm also beginning to believe that there are some good reasons why many other languages do it the other way. Part of the reason why its so hard to name this feature is that it's real name is something like "Hey, Python, you know that cool funky thing you do with defining variables in the same scope as they are assigned? Well, don't do that here." -- Talin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Talin wrote: > Some alternatives: > > use x > using x > with x -- recycle a keyword? > reuse x > use extant x > share x > common x > same x > borrow x > existing x > > Although, to be perfectly honest, the longer this discussion goes on, > the more that I find that I'm not buying Guido's argument about it being > better to define this at the point of use rather than at the point of > definition. I agree with him that "point of use" is more Pythonic, but > I'm also beginning to believe that there are some good reasons why many > other languages do it the other way. > > Part of the reason why its so hard to name this feature is that it's > real name is something like "Hey, Python, you know that cool funky thing > you do with defining variables in the same scope as they are assigned? > Well, don't do that here." (Followup to my own comment) There are really 3 places where you can indicate that a variable is to be reused instead of redefined: 1) The point of definition in the outer scope, 2) A declaration in the inner scope, and 3) The actual point of assignment. #1 is what I've been pushing for, #2 is what most of the discussion has been about, #3 has been talked about a little bit in the context of an augmented assignment operator. I actually like #3 a little better than #2, but not with a new operator. I'm thinking more along the lines of a keyword that modifies and assignment statement: rebind x = 10 Other possible keywords are: modify, mutate, change, update, change, etc... My gut feeling is that most code that wants to use this feature only wants to use it in a few places. A good example is fcgi.py (implements WSGI for FastCGI), where they use a mutable array to store a flag indicating whether or not the headers have already been sent. -- Talin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On 7/9/06, Talin <[EMAIL PROTECTED]> wrote: > Talin wrote: > > Some alternatives: > > > > use x > > using x > > with x -- recycle a keyword? > > reuse x > > use extant x > > share x > > common x > > same x > > borrow x > > existing x Of these, I like reuse, share, common slightly better than the rest. > > Although, to be perfectly honest, the longer this discussion goes on, > > the more that I find that I'm not buying Guido's argument about it being > > better to define this at the point of use rather than at the point of > > definition. I agree with him that "point of use" is more Pythonic, but > > I'm also beginning to believe that there are some good reasons why many > > other languages do it the other way. Well, I still don't like point of definition. It means that something far away can change the interpretation of something local. The reason other languages do it differently is that variable declarations are obligatory. It's really unacceptable that when I see def foo(): x = 12 I would have to search the entire module for a possible definition of a global named 'x' to see whether the x assigned to here is local or not. > > Part of the reason why its so hard to name this feature is that it's > > real name is something like "Hey, Python, you know that cool funky thing > > you do with defining variables in the same scope as they are assigned? > > Well, don't do that here." Sorry, that sounds like a B.S. argument. You can translate most language constructs into long sentences if you want to. > (Followup to my own comment) > > There are really 3 places where you can indicate that a variable is to > be reused instead of redefined: 1) The point of definition in the outer > scope, 2) A declaration in the inner scope, and 3) The actual point of > assignment. > > #1 is what I've been pushing for, #2 is what most of the discussion has > been about, #3 has been talked about a little bit in the context of an > augmented assignment operator. > > I actually like #3 a little better than #2, but not with a new operator. > I'm thinking more along the lines of a keyword that modifies and > assignment statement: > > rebind x = 10 > > Other possible keywords are: modify, mutate, change, update, change, etc... A problem with this is the ambiguity if some assignments to x use the rebind keyword and others don't. Then there's a local x and also a nonlocal x. When x is used in an expression (even on the RHS of a rebind statement!) it would be interpreted as the local one. > My gut feeling is that most code that wants to use this feature only > wants to use it in a few places. A good example is fcgi.py (implements > WSGI for FastCGI), where they use a mutable array to store a flag > indicating whether or not the headers have already been sent. Then let's allow nonlocal x = 12 as a shortcut for nonlocal x x = 12 Bash users should be familiar with this from e.g. export FOO=bar. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Missing" 2.5 feature
On 7/9/06, Tim Peters <[EMAIL PROTECTED]> wrote: > Just to make life harder ;-), I should note that code, docs and tests > for sys._current_frames() are done, on the tim-current_frames branch. > All tests pass, and there are no leaks in the new code. It's just a > NEWS blurb away from being just another hectic release memory :-) There hasn't been much positive response (in the original thread or here). Given you forgot about it for over a year, how important can it be? :-) What's the justifcation to add this feature, but none of the others? Can we defer this to 2.6? n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] xml issue in 2.5
http://python.org/sf/1513611
xml.sax.ParseException weirdness in python 2.5b1. The following code
doesn't work:
from xml.sax import make_parser, SAXParseException
parser = make_parser()
try:
parser.parse(StringIO('invalid'))
except SAXParseException:
print 'caught it!'
Any comments?
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xml issue in 2.5
Neal Norwitz wrote:
> http://python.org/sf/1513611
> xml.sax.ParseException weirdness in python 2.5b1. The following code
> doesn't work:
>
> from xml.sax import make_parser, SAXParseException
>
> parser = make_parser()
> try:
>parser.parse(StringIO('invalid'))
> except SAXParseException:
>print 'caught it!'
>
> Any comments?
The problem can be simplified to this:
py> import xml.sax,xmlcore.sax,sys
py> sys.modules['xml.sax'] is sys.modules['xmlcore.sax']
False
One way to fix this would be to never refer to "xmlcore"
explicitly (i.e. import from xml.sax._exceptions in
expatreader), but I guess that would defeat the purpose
of the xmlcore renaming.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Missing" 2.5 feature
On Sunday 09 July 2006 11:31, Tim Peters wrote: > Back in: > > > http://mail.python.org/pipermail/python-dev/2005-March/051856.html > > I made a pitch for adding: > > sys._current_frames() > > to 2.5, which would return a dict mapping each thread's id to that > thread's current (Python) frame. As noted there, an extension > module exists along these lines that's used at least by the popular > Zope DeadlockDebugger product, but it's not possible to do it > correctly in an extension. The latter is why it needs to be in the > core (so long as it's in an extension, it risks segfaulting, > because the core's internal `head_mutex` lock isn't exposed). > > I forgot about this but was recently reminded. How much opposition > would there be to sneaking this into 2.5b2? It would consist of > adding a relatively simple new function, docs, and tests; since it > wouldn't _change_ any existing code, it would have a hard time > breaking anything that currently works. Hm. Would it be a smaller change to expose head_mutex so that the external module could use it? I'm really not keen on this seeming tide of new features that seem to be popping up. We're only a few days away from the second and final planned beta - it's getting _awfully_ late to be slotting in new features. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Missing" 2.5 feature
On 09/07/2006, at 9:05 AM, Anthony Baxter wrote: > I'm really not keen on this seeming tide of new features that > seem to be popping up. We're only a few days away from the second and > final planned beta - it's getting _awfully_ late to be slotting in > new features. And besides, one person has already been told that there's absolutely no new features added after the beta freeze, ever. Richard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Missing" 2.5 feature
Richard Jones wrote: > On 09/07/2006, at 9:05 AM, Anthony Baxter wrote: >> I'm really not keen on this seeming tide of new features that >> seem to be popping up. We're only a few days away from the second and >> final planned beta - it's getting _awfully_ late to be slotting in >> new features. > > And besides, one person has already been told that there's absolutely > no new features added after the beta freeze, ever. Last time I looked, features approved by the BDFL and/or release manager were OK to go in. Besides, quite a few bugfixes are likely to introduce more "new features" than this ;) Cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
