Re: [Python-Dev] Lexical scoping in Python 3k
Josiah Carlson wrote: > I had hoped that there would be a response to my second (and I believe > more applicable statement); "if the feature is really only useful for > generally trivial cases *without* the feature, then making them even > more trivial, I think, is a bit of over optimization." It really depends on how common the trivial case is. In other words, multiply the savings for each occurance times the number of occurances. (Unfortunately, I don't know what units to measure said savings in - is there a unit of 'mental disconnect' or unintuitiveness? :) In an idealy world, the language would allow everything to be said in the most comprehensible way possible. Longer and more verbose ways of stating something are at an inherent disadvantage in this, simply because of the time it takes to scan and absorb the information by the human brain. However, losing excess syntax has to be done in a way that doesn't also lose information. Highly compressed representations of a concept may require such a level of abstraction that it is as much work to puzzle out their meaning as it would be to read the longer version and more. To put it another way - I am an advocate of applying Claude Shannon's theory of information to language design. The highest level of compression should be used for expressions that occur the most frequently. > As for a solution, I find the "global means 'not local'" proposition is > the least undesireable of the possibilities. It suffers from a change > in semantics and potential name masking issues, but I don't believe > these are any more serious than normal global masking for the former, > and the latter is solvable with a __future__ (at least for 2.6). I'm a > solid -0 on this particular proposition, which is far better than the -1 > I am on all of the other recent lexical scoping propositions. I'd say that the more common case is where you want global to really mean global - that is, you want to be able to write to some module-level variable, regardless of how deeply nested your function scope is. While being able to access the 'next outer scope' is occasionally useful, it's not all that common. So changing the behavior of 'global' in this case would be both confusing (since it no longer means 'global'), and less useful (because it doesn't match the most common case.) (This assumes that I haven't completely understood the meaning of the phrase 'not local' - I assumed that it means 'not defined in this scope') Of course, the reason why it's not all that common may be because of the fact that it's not as easy to do, and so people tend to (consciously or otherwise) avoid that pattern in their designs. That being said, I don't think that's necessarily such a bad thing. Python isn't Scheme, and the scoping rules of Python are IMHO more oriented towards practicality and common sense than theoretical purity. This is why I'm not bothered by the fact that Python doesn't create a new scope for loop statements and such. Most of the time, this is what you want. It does mean that you need to name all of your variables uniquely, but that's good programming style in any case. The same is true for local variables not needing to be specially declared as 'my' or 'var' - most of the time, a local variable is what you want. On the other hand, the thing about theoretical purity is that it can be so mouth-wateringly powerful at times. For example, a language that supports closures is, IMHO, at least twice as powerful as a language that doesn't -- because you can use them in so many different and interesting ways. OK, so about the lexical scoping issue - let me brainstorm a moment: One idea would be to introduce the keyword 'local' which would have the effect of capturing any 'global' statements in any enclosing scope. So for example: f = 1 def a(): local f f = 2 def b(): global f f = 3 So in this case, the 'global' statement, which would normally associate 'f' with the outermost (module-level) scope, would instead associate 'f' with the innermost 'local' declaration of that variable. So in the above example, assigning 3 to f assigns it to the middle scope, but does not affect the module-level definition. Admittedly, that's a bit confusing and also verbose, considering that you are not only adding an extra keyword, but also using two statements to specify the home of one variable. Another alternative would be a way to declare an explicitly scoped variable. Lets use the keyword 'my' to indicate this: f = 1 def a(): my f = 2 def b(): f = 3 In this case, what the 'my' statement is doing is indicating that this scope 'owns' the definition of 'f' -- in other words, the definition is hoisted out of any enclosed scopes. So again, in the above example, the innermost assignment will be to the definition of 'f' in the middle scope. What's interesting about this is that you c
Re: [Python-Dev] Proposal to eliminate PySet_Fini
[Jack Diederich] >> PyObject_MALLOC does a good job of reusing small allocations but it >> can't quite manage the same speed as a free list, especially for things that >> have some extra setup involved (tuples have a free list for each length). [Martin v. Löwis] > I would question that statement, for any practical purposed. The cost of > tuple comes from setting the elements to NULL, and that has to be done > regardless of whether they were allocated new or came from the list. Except _that_ overhead is trivial for small tuples, and small tuples are the only kind the free lists cache. There are many other overheads. If a tuple is taken off a free list, we get to skip integer multiplication and division checking for overflow before calling PyObject_GC_NewVar. We also get to skip the call to PyObject_GC_NewVar. That in turns skips another integer multiplication in the _PyObject_VAR_SIZE macro, and a call to _PyObject_GC_Malloc. That it turn skips a call to PyObject_MALLOC, and conditionals checking whether it's time to trigger a gc collection. All of that is highly significant compared to the cost of setting at most a handful of slots to NULL inline. > Likewise, the GC management has to be done regardless. _PyObject_GC_TRACK expands to 5 inlined simple stores, and a predictable branch, so it is often more expensive than setting the tuple slots to NULL. But, as above, we get to skip three layers of function call and "will it overflow?" arithmetic in the service of _setting up_ an object for gc initially. Only the gc track/untrack pair remains for tuples in a free list. > So I expect that the speedup is rather minor, and not worth it. Depends on the app :-) Here's a test case that gets supernatural benefit from small-tuple caching: """ def doit(): N1000 = [None] * 1000 basetup = (5,) for i in N1000: tups = [] push = tups.append for j in xrange(10): for k in N1000: push(basetup * j) from time import clock as now times = [] for i in range(3): start = now() doit() finish = now() times.append(finish - start) print sorted(times) """ With current trunk that printed [2.9363677646013846, 2.9489729031005703, 2.9689538729183949] After changing #define MAXSAVEDTUPLES 2000 to #define MAXSAVEDTUPLES 0 the times zoomed to [4.5894824930441587, 4.6023111649343242, 4.629560027293957] That's pretty dramatic. OTOH, I don't have any apps that do that <0.5 wink>, and there's another downside: on SF recently, someone complained that the 2.5 obmalloc work to release unused arenas wasn't doing much in his (perhaps equally artificial -- don't know) test case. It surprised me too, so I dug into it. The problem turned out to be that piles of arenas were being kept "artificially" alive because obmalloc was the original source of thousands of tuple objects being kept alive (from obmalloc's POV) in tupleobject.c's free lists. If you're unlucky, it only takes one tiny tuple in one free list to keep an entire 256KB arena alive -- and if you're very unlucky, you manage to allocate objects in such a way that this happens repeatedly. His test also created lots of dicts along the way, and each arena got mostly filled up with dict objects and a relative handful of small tuples. By the time all of this became trash, the tuples were spread over a few hundred areans, which effectively became immortal. While it doesn't make any real sense, I've seen repeatedly that users _try_ calling gc.collect() in such cases (doesn't make sense because it has nothing to do with cyclic gc). But that suggests it could be a _pragmatic_ win to add an internal "clear all known free lists" function, which gc could call at times, or even just be forced by the user via a `gc` entry point or gc.collect() option. The immortal & unbounded int and float free lists don't cause obmalloc arenas to stay alive unduly, because they get their memory in chunks straight from the system malloc(). But they have to be the cause of the most frequent source of complaints from newbies and Zope users ;-), who do things like range(1000) and then marvel that some 120MB of VM is still being used after nuking the list and doing a gc.collect(). I get weary of explaining that one :-(. ___ 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] Lexical scoping in Python 3k
Josiah Carlson wrote: > I had hoped that there would be a response to my second (and I believe > more applicable statement); "if the feature is really only useful for > generally trivial cases *without* the feature, then making them even > more trivial, I think, is a bit of over optimization." I don't think "trivial" is the right word to use here, since it implies something that's of so little importance that it can be ignored. But the simple cases are precisely the ones where this wart hurts the most, so we can't ignore them. Arguments that a feature is undesirable because this or that workaround exists seem like post-hoc justifications to me. Think about it the other way around -- if writing to outer scopes had been straightforward from the beginning, would you be arguing for the *removal* of that ability? Would it even have occurred to anyone to do such a thing? -- Greg ___ 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] Lexical scoping in Python 3k
Talin wrote: > To put it another way - I am an advocate of applying Claude Shannon's > theory of information to language design. The highest level of > compression should be used for expressions that occur the most frequently. I believe the proposal in question would cause no net worsening in this information content, and may actually improve it slightly, due to allowing a few things to be written in a shorter and clearer way, while allowing the vast majority of existing things to be written in exactly the same way. > I'd say that the more common case is where you want global to really > mean global - that is, you want to be able to write to some module-level > variable, regardless of how deeply nested your function scope is. It would still mean that, except in the (expected to be *extremely* rare) case where you happened to have a variable with the same name assigned in some intermediate scope. Such cases would be easily fixed by renaming the intermediate variable -- using a name of shorter or equal length, if you like, to keep the information content up. :-) > So changing the behavior of 'global' in this case > would be both confusing (since it no longer means 'global'), An alternative would be to change the keyword as well, to something like 'outer', which would better match its semantics. But if that were done, I would argue for the *removal* of the existing 'global' keyword, which would then be almost completely redundant. This would break large amounts of existing code, however, and it's highly dubious whether that would be worth the small increase in pendantic accuracy, even in Py3k. We're not supposed to be *gratuitously* breaking things in Py3k, after all. > (This assumes that I haven't completely understood the meaning of the > phrase 'not local' - I assumed that it means 'not defined in this scope') Yes, the new meaning would be "in the next outermost scope where there is an assignment to this name, or the module scope if you get that far". > Python isn't Scheme, and the scoping rules of Python are > IMHO more oriented towards practicality and common sense > than theoretical purity. Yes, but I find it hard to regard being *forbidden* from assigning to intermediate scopes as something driven by practical need rather than just being a historical accident. Back when there were strictly two scopes, many people argued themselves blue in the face that this was actually a *good* thing, even if you didn't realise it, and that Python was doing you a favour by enforcing it. Eventually a measure of sanity prevailed, and we got something a lot more like traditional lexical scoping. But one remnant of the old system remained, like a vestigial organ -- the 'global' statement that reaches all the way out to the module scope, regardless of what exists in between. To someone used to lexical scoping in almost any other language that has it, this is a *very* strange and unintuitive thing. Looking back, I think the meaning of 'global' should have been redefined right then at the same time. That would have been the logical and consistent thing to do, and in my opinion would have resulted in a scoping model that was simpler, more useful and no less practical. The most theoretically pure thing would have been to change it to 'outer' at the same time, but that would have broken too much code, and would therefore not have been practical. See, I'm not immune to practicality arguments. :-) > One idea would be to introduce the keyword 'local' which would have the > effect of capturing any 'global' statements in any enclosing scope. That seems unnecessary to me. Or at least not necessary enough to be worth the extra complexity in the scoping model. -- Greg ___ 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] Lexical scoping in Python 3k
Josiah> As for a solution, I find the "global means 'not local'" Josiah> proposition is the least undesireable of the possibilities. It Josiah> suffers from a change in semantics and potential name masking Josiah> issues... Pychecker and PyLint both already identify cases where builtins are masked by locals or module globals (and may identify cases where locals mask module globals - I don't recall). I suspect both could be generalized in this regard without a huge effort. That's probably the best place for this sort of warning. Skip ___ 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] Lexical scoping in Python 3k
> I don't think "trivial" is the right word to use here, > since it implies something that's of so little importance > that it can be ignored. But the simple cases are precisely > the ones where this wart hurts the most, so we can't > ignore them. I'd like to inject an example that might help make this discussion more concrete. Consider the following function: def for_each(seq, f): for i in seq: f(i) I'm sure I've seen more than one instance of someone on comp.lang.python trying to do the equivalent of using a function such as this one to compute the sum of the elements of a sequence as follows: def sum(seq): result = 0 def accum(i): result += i for_each(seq, accum) return result and wonder why it doesn't work. Still odder, why it doesn't work and the following does: def sum(seq): result = [0] def accum(i): result[0] += i for_each(seq, accum) return result[0] Transforming the first definition of sum above into the second may be trivial, but only if you've encountered the technique before. Moreover, the first version of sum uses a technique that is more than 45 years old (!), as it was available to Algol 60 programmers. ___ 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] Proposal to eliminate PySet_Fini
Tim Peters wrote: > With current trunk that printed > > [2.9363677646013846, 2.9489729031005703, 2.9689538729183949] > > After changing > > #define MAXSAVEDTUPLES 2000 > > to > > #define MAXSAVEDTUPLES 0 > > the times zoomed to > > [4.5894824930441587, 4.6023111649343242, 4.629560027293957] > > That's pretty dramatic. Interesting. I ran this through gprof, and found the following changes to the number of function calls with-cache without-cache PyObject_Malloc 5905824055245 tupletraverse 3357467863194 visit_decref 131333 197199417 visit_reachable131333 197199417 collect17 33006 (for reference:) tuplerepeat 30003000 According to gprof, these functions (excluding tuplerepeat) together account for 40% of the execution time in the without-cache (i.e. MAXSAVEDTUPLES 0) case. So it appears that much of the slowdown in disabling the fast tuple allocator is due to the higher frequency of garbage collection in your example. Can you please re-run the example with gc disabled? Of course, it's really no surprise that GC is called more often: if the tuples are allocated from the cache, that doesn't count as an allocation wrt. GC. It so happens that your example just triggers gc a few times in its inner loop; I wouldn't attribute that overhead to obmalloc per se. 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] Lexical scoping in Python 3k
On 7/3/06, Andrew Koenig <[EMAIL PROTECTED]> wrote: > > I don't think "trivial" is the right word to use here, > > since it implies something that's of so little importance > > that it can be ignored. But the simple cases are precisely > > the ones where this wart hurts the most, so we can't > > ignore them. > > I'd like to inject an example that might help make this discussion more > concrete. > > Consider the following function: > > def for_each(seq, f): > for i in seq: > f(i) > > I'm sure I've seen more than one instance of someone on comp.lang.python > trying to do the equivalent of using a function such as this one to compute > the sum of the elements of a sequence as follows: > > def sum(seq): > result = 0 > def accum(i): > result += i > for_each(seq, accum) > return result > > and wonder why it doesn't work. Still odder, why it doesn't work and the > following does: > > def sum(seq): > result = [0] > def accum(i): > result[0] += i > for_each(seq, accum) > return result[0] > > Transforming the first definition of sum above into the second may be > trivial, but only if you've encountered the technique before. Moreover, the > first version of sum uses a technique that is more than 45 years old (!), as > it was available to Algol 60 programmers. Much though the Algol 60 tickles my nostalgia (it was my first programming language!) I don't think that it's a particularly strong argument. I like to think that we have better ways these days. I think you need to come up with a better motivating example; the above is particular un-idiomatic Python. It starts by defining a higher-order function for_each that has little to offer over writing an explicit for loop, and then uses this to motivate writing a simple operation (result += i) as a function instead so that it fits in the inconvenient for_each() API. I understand that both for_each() and accum() are just examples of more complicated functions, but I can't help thinking that the problem here only occurs for very *simple* functions in the place of accum(); a more complicated form of accum would likely be a bound method of a class instance which carries the state. A better way to decompose these kinds of problems is probably by using generators. The equivalent of for_each() would not take a function parameter but *yield* the successive values instead of calling f() with successive values; e.g.: def for_each(seq): for i in seq: yield i Then the sum() function could be written like this: def sum(seq): result = 0 for i in for_each(seq): result += i return result -- --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] Lexical scoping in Python 3k
> Much though the Algol 60 tickles my nostalgia (it was my first > programming language!) I don't think that it's a particularly strong > argument. I like to think that we have better ways these days. Even if so, that's not the point I was trying to make. The point is that there is a programming technique that is widely used, works in many languages, and has been around for 45 years; and when you try to use it in Python, it fails. I believe that such failures, even if there are alternative ways of solving the problems that engender them, are barriers to learning that should be removed if it is possible to do so without substantial cost. ___ 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] Moving the ctypes repository to python.org
Martin v. Löwis schrieb: > Thomas Heller wrote: >> - Do I need special rights to call 'svnadmin load' to import this dumpfile >> into Python SVN, or are the normal commit rights sufficient? > > It's called "svnadmin" for a reason :-) > > Neal Norwitz or myself will have to do that; we need to do it on the > repository machine locally. I would likely take subversion write > access offline for the time of the import, so that I can rollback > the entire repository in case of an operator mistake. Please tell me when you or Neal have time for the import. >> What exactly is the URL/PATH where it should be imported (some sandbox, >> I assume)? > > My view is that this is the "projects" repository; with ctypes being a > project, it should go into the root directory (i.e. as a sibling to > python, peps, distutils, stackless, ...). If you prefer to see it in > sandbox, this could work as well. Having it in "projects" is fine, this matches the directory structure that cvs2svn creates (ctypes/trunk, ctypes/tags, ctypes/branches). >> - What about the Python trunk? Should changes from the sandbox be merged >> into Modules/_ctypes and Lib/ctypes, or would it be better (or possible at >> all) >> to use the external mechanism? > > I would prefer to see two-way merges going on, at least until 2.5 is > released (i.e. no changes to Modules/ctypes except for bug fixes). Ok. > Using svn:external is a risky thing wrt. to branching/tagging: > > When we tag the Python tree, we want to tag the entire source tree. > With svn:external, only the external link would be in the tag, > i.e. later changes to the external link would modify old tags. > This is undesirable. > > This problem could be solved with a versioned external link; > this would mean that ctypes could not be edited directly, but > that one would have to go through the original repository > URL to perform modifications, and then update the external > link. > > So I think I still would prefer two-way merges. There are > tools to make the merges pretty mechanic. I have no experience at all with svn:external, so that's fine with me too. Thanks, Thomas ___ 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] Moving the ctypes repository to python.org
Martin v. Löwis schrieb: > Thomas Heller wrote: >> - Do I need special rights to call 'svnadmin load' to import this dumpfile >> into Python SVN, or are the normal commit rights sufficient? > > It's called "svnadmin" for a reason :-) > > Neal Norwitz or myself will have to do that; we need to do it on the > repository machine locally. I would likely take subversion write > access offline for the time of the import, so that I can rollback > the entire repository in case of an operator mistake. Please tell me when you or Neal have time for the import. >> What exactly is the URL/PATH where it should be imported (some sandbox, >> I assume)? > > My view is that this is the "projects" repository; with ctypes being a > project, it should go into the root directory (i.e. as a sibling to > python, peps, distutils, stackless, ...). If you prefer to see it in > sandbox, this could work as well. Having it in "projects" is fine, this matches the directory structure that cvs2svn creates (ctypes/trunk, ctypes/tags, ctypes/branches). >> - What about the Python trunk? Should changes from the sandbox be merged >> into Modules/_ctypes and Lib/ctypes, or would it be better (or possible at >> all) >> to use the external mechanism? > > I would prefer to see two-way merges going on, at least until 2.5 is > released (i.e. no changes to Modules/ctypes except for bug fixes). Ok. > Using svn:external is a risky thing wrt. to branching/tagging: > > When we tag the Python tree, we want to tag the entire source tree. > With svn:external, only the external link would be in the tag, > i.e. later changes to the external link would modify old tags. > This is undesirable. > > This problem could be solved with a versioned external link; > this would mean that ctypes could not be edited directly, but > that one would have to go through the original repository > URL to perform modifications, and then update the external > link. > > So I think I still would prefer two-way merges. There are > tools to make the merges pretty mechanic. I have no experience at all with svn:external, so that's fine with me too. Thanks, Thomas ___ 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] weakattr
> I like the added functionality offered with weakattrs as defined. I'm > not terribly in love with the syntax of their creation, and I'm curious > as to how it plays with __slots__ weakattrs are data descriptors, just like properties etc. they are part of the class, not the instance, so there shouldn't be any trouble with mixing those with __slots__ moreover, adding those to stdlib is very staight-forward. we don't even need to introduce a new module. if people show interest, i'll write a bit of a longer doc string and add some unit tests (although there's not much to test :) ) > Toss it out in python-list, I think some people over there would be able > to offer more feedback. will do... although i doubt they will offer any -tomer On 7/2/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > "tomer filiba" <[EMAIL PROTECTED]> wrote: > > weakattr (weak attributes) are attributes that are weakly referenced > > by their containing object. they are very useful for cyclic references -- > > an object that holds a reference to itself. > > I like the added functionality offered with weakattrs as defined. I'm > not terribly in love with the syntax of their creation, and I'm curious > as to how it plays with __slots__ (not quite having the time to look at > its implementation right now), but it is quite explicit, so I can get > past that. It would allow us to say, "stop using __del__, use weakattrs", > but I'm not sure how well that would work, generally. > > Toss it out in python-list, I think some people over there would be able > to offer more feedback. > > - Josiah > > ___ 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] Time-out in URL Open
I need a timeout in urlopen, just to be able to make:
>>> urllib2.urlopen("http://no.host.org";, timeout=2)
This is actually not possible, but I'll make it work.
I want to know, please, if this is useful in general, for me to post a
patch in SF.
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] Time-out in URL Open
On Monday 03 July 2006 14:07, Facundo Batista wrote: > I want to know, please, if this is useful in general, for me to post a > patch in SF. It seems like something that should be easy, and lots of people need to consider this for applications. -Fred -- Fred L. Drake, Jr. ___ 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] Time-out in URL Open
Facundo Batista wrote:
urllib2.urlopen("http://no.host.org";, timeout=2)
>
> This is actually not possible, but I'll make it work.
>
> I want to know, please, if this is useful in general, for me to post a
> patch in SF.
While it might be useful, it can only be added to Python 2.6 now.
So take your time with that patch.
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] Lexical scoping in Python 3k
On 7/3/06, Andrew Koenig <[EMAIL PROTECTED]> wrote: > > Much though the Algol 60 tickles my nostalgia (it was my first > > programming language!) I don't think that it's a particularly strong > > argument. I like to think that we have better ways these days. > > Even if so, that's not the point I was trying to make. The point is that > there is a programming technique that is widely used, works in many > languages, and has been around for 45 years; and when you try to use it in > Python, it fails. That's true for lots of things that have been around for a long time. Can you provide a better example? (The use of += is not particularly relevant to the example; it could just as well have said "result = result + i".) > I believe that such failures, even if there are alternative ways of solving > the problems that engender them, are barriers to learning that should be > removed if it is possible to do so without substantial cost. And that is of course the crucial question. Probably the only proposal that has any chance of succeeding is to extend the 'global' statement so that it also applies to variables in intermediate outer scopes; or perhaps a new keyword (since "global" is not a very good name for the extended semantics). We would have to decide what this example would do: def outer(): def inner1(x): global a a = x def inner2(): return a return inner1, inner2 f1, f2 = outer() g1, g2 = outer() f1(42) g1(0) print f2()# Does it print 0 or 42 ??? In current Python this prints 0: there's only one (global) variable a, and the call to g1(0) overrides the value that was stored by f1(42). If global were changed to mean "nonlocal" what should it do? The question the example poses is that a is not initialized except in inner1() -- we somehow have to decide whether this is an error, or whether it chooses some well-defined outer scope, with the choices being the nearest enclosing scope or the outermost (truly global) scope. We have one guideline: if there is exactly one outer scope that defines a variable named a, we would like it to be referenced (by the 'global a') statement and the variable references governed by it automatically. Also, of there's more than one such scope, we'd like it to reference the innermost one. But this doesn't have a natural extension to what should happen if there's no such scope! Perhaps the best solution would be to make it an error if there wasn't a visible variable named a in an outer scope. That would suit me fine because I'd like to migrate towards more static analysis of variables anyway. If that means equipping modues with traps for attempts to store arbitrary variables into their namespaces, that's fine with me (as long as there's some escape -- and of course instancs and classes remain fully dynamic). -- --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] Time-out in URL Open
To fake things like this, socket.setdefaulttimeout() was added, though
I don't know if it actually works. Have you tried that?
--Guido
On 7/3/06, Facundo Batista <[EMAIL PROTECTED]> wrote:
> I need a timeout in urlopen, just to be able to make:
>
> >>> urllib2.urlopen("http://no.host.org";, timeout=2)
>
> This is actually not possible, but I'll make it work.
>
> I want to know, please, if this is useful in general, for me to post a
> patch in SF.
>
> Regards,
>
> --
> .Facundo
>
> Blog: http://www.taniquetil.com.ar/plog/
> PyAr: http://www.python.org/ar/
> ___
> 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] Time-out in URL Open
Facundo> I need a timeout in urlopen, just to be able to make:
urllib2.urlopen("http://no.host.org";, timeout=2)
Facundo> This is actually not possible, but I'll make it work.
Facundo> I want to know, please, if this is useful in general, for me to
Facundo> post a patch in SF.
As others have posted, yes, it would be useful for 2.6. However, you should
consider how that might be applied to the other Internet service modules
(ftplib, telnetlib, urllib, etc).
Skip
___
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] Time-out in URL Open
Guido> To fake things like this, socket.setdefaulttimeout() was added, Guido> though I don't know if it actually works. Have you tried that? I'm pretty sure it does, but is a rather blunt instrument for the task, as it affects all socket connections the app might make. Skip ___ 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] Time-out in URL Open
On Mon, 3 Jul 2006, Guido van Rossum wrote: > To fake things like this, socket.setdefaulttimeout() was added, though > I don't know if it actually works. Have you tried that? [...] It works. I think there's some issue with SSL, though (can't seem to find the issue now). Of course, feeding through the timeout to the individual protocol modules would be a good thing. John ___ 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] 2.5 and beyond
For Common Lispers and probably Schemers, Python has some surprising semantics around scope and lifetime extent of variables. Three that leap out at me are: * function parameters with default values are NOT new bindings for each invocation, so a default value of [] changes if you destructively modify this list object in the function * loop variables are NOT distinct lexical variables. The binding gloms on to a variable in the function's scope, both changing that lexical binding and not creating a new one for the loop (that goes away when the loop's scope ends) * loop variables are NOT distinct bindings per iteration, leading to the surprising results below Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Janssen Sent: Friday, June 30, 2006 6:31 PM To: Giovanni Bajo Cc: Phillip J. Eby; Ka-Ping Yee; Guido van Rossum; Tim Peters; python-dev@python.org Subject: Re: [Python-Dev] 2.5 and beyond > >>> a = [] > >>> for i in range(10): > ... a.append(lambda: i) > ... > >>> print [x() for x in a] > [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] Isn't this exactly what you'd expect? Maybe I've been writing Python for too long... :-). Bill ___ 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/billchi%40microsoft.co m ___ 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] 2.5 and beyond
"Bill Chiles" <[EMAIL PROTECTED]> wrote: > > For Common Lispers and probably Schemers, Python has some surprising > semantics around scope and lifetime extent of variables. Three that > leap out at me are: One thing to remember is that Python is not Scheme/Lisp. It borrows some ideas from Scheme/Lisp, but that borrowing does not necessitate a it also use a completely equivalent scoping mechanism. From what I have been hearing about Python 2.6, and 3.0, the three "surprises" you describe are not going to be "fixed" (with respect to expected Scheme/Lisp semantics). Feel free to argue as to why they should be "fixed" in Py3k (unless Guido says, "you're dreaming"), but please do so in the py3k list. - Josiah > * function parameters with default values are NOT new bindings for each > invocation, so a >default value of [] changes if you destructively modify this list > object in the function > * loop variables are NOT distinct lexical variables. The binding gloms > on to a variable in the >function's scope, both changing that lexical binding and not creating > a new one for the >loop (that goes away when the loop's scope ends) > * loop variables are NOT distinct bindings per iteration, leading to > the surprising results >below ___ 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] 2.5 and beyond
On 7/4/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > One thing to remember is that Python is not Scheme/Lisp. It borrows > some ideas from Scheme/Lisp, I can say it stronger. Any resemblance between Python and Scheme or Lisp is purely a coincidence. Neither language is in Python's ancestry, at least not explicitly; I'd never used or tried to learn Scheme when I started Python (still haven't) and my Lisp experience was limited to copying Emacs startup code from friends (still is). -- --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
