Re: [Python-Dev] defaultproperty
Calvin Spealman wrote: > I mean, come on, its like making a module just to store a bunch of > unrelated types just to lump them together because they're types. import types ___ 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] New PEP 342 suggestion: result() and allow "return with arguments" in generators (was Re: PEP 342 suggestion: start(), __call__() and unwind_call() methods)
Greg Ewing wrote: > Nick Coghlan wrote: > > >>Sometimes I miss the obvious. There's a *much*, *much* better place to store >>the return value of a generator than on the StopIteration exception that it >>raises when it finishes. Just save the return value in the *generator*. > > > I'm not convinced that this is better, because it would > make value-returning something specific to generators. > > On the other hand, raising StopIteration(value) is something > that any iterator can easily do, whether it's implemented > as a generator, a Python class, a C type, or whatever. > > Besides, it doesn't smell right to me -- sort of like returning > a value from a function by storing it in a global rather than > using a return statement. Yeah, the various responses have persuaded me that having generators resemble threads in that they don't have a defined "return value" isn't a bad thing at all. Although that means I've gone all the way back to preferring the status quo - if you want to pass data back from a generator when it terminates, just use StopIteration(result). I'm starting to think we want to let PEP 342 bake for at least one release cycle before deciding what (if any) additional behaviour should be added to generators. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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] Extending tuple unpacking
Fred L. Drake, Jr. wrote: > On Sunday 09 October 2005 22:44, Greg Ewing wrote: > > I'm aware of the differences, but I still see a strong > > similarity where this particular feature is concerned. > > The pattern of thinking is the same: "I want to deal > > with the first n of these things individually, and the > > rest collectively." > > Well stated. I'm in complete agreement on this matter. It also works for situations where "the first n items are mandatory, the rest are optional". This usage was brought up in the context of a basic line interpreter: cmd, *args = input.split() Another usage is to have a Python function which doesn't support keywords for its positional arguments (to avoid namespace clashes in the keyword dict), but can still unpack the mandatory arguments easily: def func(*args, **kwds): arg1, arg2, *rest = args # Unpack the positional arguments Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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
[Python-Dev] PEP 3000 and exec
This might be minor-- but I didn't see anyone mentioning it so far. If `exec` functionality is to be provided, then I think it still should be a keyword for the parser to know; currently bytecode generation is affected if `exec` is present. Even if that changes for Python 3k (we don't know yet), the paragraph for exec should be annotated with a note about this issue. ___ 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] defaultproperty
Guido van Rossum wrote: > On 10/9/05, Jim Fulton <[EMAIL PROTECTED]> wrote: > >>Based on the discussion, I think I'd go with defaultproperty. > > > Great. > > >>Questions: >> >>- Should this be in builtins, alongside property, or in >> a library module? (Oleg suggested propertytools.) >> >>- Do we need a short PEP? > > > I think so. From the responses I'd say there's at most lukewarm > interest (including from me). Hm, I saw several responses from people who'd built something quite similar. This suggests to me that this is a common need. > You might also want to drop it and just > add it to your personal (or Zope's) library. I have something like this in Zope's library. I end up with a very small package that isn't logically part of other packages, but that is a dependency of lots of packages. I don't like that, but I guess I should get over it. I must say that I am of 2 minds about things like this. On the one hand, I'd like Python's standard library to be small with packaging systems to provide "extra batteries". OTOH, I often find small tools like this that would be nice to have readily available. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] C.E.R. Thoughts
Congragulations heartily given. I missed the ternary op in c... Way to go! clean and easy and now i can do: if ((sys.argv[1] =='debug') if len(sys.argv) > 1 else False): pass and check variables IF AND ONLY if they exist, in a single line! but y'all knew that.. ___ 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] C.E.R. Thoughts
On Sat, Oct 08, 2005 at 08:04:13PM -0400, jamesr wrote: > if ((sys.argv[1] =='debug') if len(sys.argv) > 1 else False): > pass Very good example! Very good example why ternary operators must be forbidden! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] C.E.R. Thoughts
On Sat, 8 Oct 2005 20:04:13 -0400, jamesr <[EMAIL PROTECTED]> wrote: >Congragulations heartily given. I missed the ternary op in c... Way to >go! clean and easy and now i can do: > >if ((sys.argv[1] =='debug') if len(sys.argv) > 1 else False): > pass > >and check variables IF AND ONLY if they exist, in a single line! if len(sys.argv) > 1 and sys.argv[1] == 'debug': ... usually-wouldn't-but-can't-pass-it-up-ly y'rs, Jp ___ 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] C.E.R. Thoughts
> Congragulations heartily given. I missed the ternary op in c... Way to > go! clean and easy and now i can do: > if ((sys.argv[1] =='debug') if len(sys.argv) > 1 else False): > pass > and check variables IF AND ONLY if they exist, in a single line! Umm... Is this a joke? ___ 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] C.E.R. Thoughts
Andrew> Umm... Is this a joke? I hope so. I must admit the OP's intent didn't make itself known to me with the cursory glance I gave it. Jp's formulation is how I would have written it. Assuming of course, that was the OP's intent. 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] Fwd: defaultproperty
On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote: > Never created for a reason? lumping things together for having the > similar usage semantics, but unrelated purposes, might be something to > avoid and maybe that's why it hasn't happened yet for decorators. If > ever there was a makethreadsafe decorator, it should go in the thread > module, etc. I mean, come on, its like making a module just to store a > bunch of unrelated types just to lump them together because they're > types. Who wants that? Like itertools? +1 for a decorators module. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Pythonic concurrency
On Fri, 2005-10-07 at 23:54, Nick Coghlan wrote: [...] > The few times I have encountered anyone saying anything resembling "threading > is easy", it was because the full sentence went something like "threading is > easy if you use message passing and copy-on-send or release-reference-on-send > to communicate between threads, and limit the shared data structures to those > required to support the messaging infrastructure". And most of the time there > was an implied "compared to using semaphores and locks directly, " at the > start. LOL! So threading is easy if you restrict inter-thread communication to message passing... and what makes multi-processing hard is your only inter-process communication mechanism is message passing :-) Sounds like yet another reason to avoid threading and use processes instead... effort spent on threading based message passing implementations could instead be spent on inter-process messaging. -- Donovan Baarda <[EMAIL PROTECTED]> ___ 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] Extending tuple unpacking
On 10/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > It also works for situations where "the first n items are mandatory, the rest > are optional". This usage was brought up in the context of a basic line > interpreter: > >cmd, *args = input.split() That's a really poor example though. You really don't want a line interpreter to bomb if the line is empty! > Another usage is to have a Python function which doesn't support keywords for > its positional arguments (to avoid namespace clashes in the keyword dict), but > can still unpack the mandatory arguments easily: > >def func(*args, **kwds): >arg1, arg2, *rest = args # Unpack the positional arguments Again, I'd be more comfortable if this was preceded by a check for len(args) >= 2. I should add that I'm just -0 on this. I think proponents ought to find better motivating examples that aren't made-up. Perhaps Raymond's requirement would help -- find places in the standard library where this would make code more readable/maintainable. -- --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] New PEP 342 suggestion: result() and allow "return with arguments" in generators (was Re: PEP 342 suggestion: start(), __call__() and unwind_call() methods)
On 10/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > I'm starting to think we want to let PEP 342 bake for at least one release > cycle before deciding what (if any) additional behaviour should be added to > generators. Yes please! -- --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] Pythonic concurrency
On Fri, 2005-10-07 at 17:47, Bruce Eckel wrote: > Early in this thread there was a comment to the effect that "if you > don't know how to use threads, don't use them," which I pointedly > avoided responding to because it seemed to me to simply be > inflammatory. But Ian Bicking just posted a weblog entry: > http://blog.ianbicking.org/concurrency-and-processes.html where he > says "threads aren't as hard as they imply" and "An especially poor > argument is one that tells me that I'm currently being beaten with a > stick, but apparently don't know it." The problem with threads is at first glance they appear easy, which seduces many beginning programmers into using them. The hard part is knowing when and how to lock shared resources... at first glance you don't even realise you need to do this. So many threaded applications are broken and don't know it, because this kind of broken-ness is nearly always intermittant and very hard to reproduce and debug. One common alternative is async polling frameworks like Twisted. These scare beginners away because a first glance, they appear hideously complicated. However, if you take the time to get your head around them, you get a better feel for all the nasty implications of concurrency, and end up designing better applications. This is the reason why, given a choice between an async and a threaded implementation of an application, I will always choose the async solution. Not because async is inherently better than threading, but because the programmer who bothered to grock async is more likely to get it right. -- Donovan Baarda <[EMAIL PROTECTED]> ___ 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] Pythonic concurrency
On Monday 10 Oct 2005 15:45, Donovan Baarda wrote: > Sounds like yet another reason to avoid threading and use processes > instead... effort spent on threading based message passing > implementations could instead be spent on inter-process messaging. I can't let that pass (even if our threaded component has a couple of warts at the moment). # Blocking thread example (uses raw_input) to single threaded pygame # display ticker. (The display is rate limited to 8 words per second at # most since it was designed for subtitles) # from Axon.ThreadedComponent import threadedcomponent from Kamaelia.Util.PipelineComponent import pipeline from Kamaelia.UI.Pygame.Ticker import Ticker class ConsoleReader(threadedcomponent): def __init__(self, prompt=">>> "): super(ConsoleReader, self).__init__() self.prompt = prompt def run(self): # implementation wart, should be "main" while 1: line = raw_input(self.prompt) line = line + "\n" self.outqueues["outbox"].put(line) # implementation wart, should be self.send(line, "outbox") pipeline( ConsoleReader(), Ticker() # Single threaded pygame based text ticker ).run() There's other ways with other systems to achieve the same goal. Inter-process based messaging can be done in various ways. The API though can look pretty much the same. (There's obviously some implications of crossing process boundaries though, but that's for the system composer to deal with, not the components). Regards, Michael. -- Michael Sparks, Senior R&D Engineer, Digital Media Group [EMAIL PROTECTED], http://kamaelia.sourceforge.net/ British Broadcasting Corporation, Research and Development Kingswood Warren, Surrey KT20 6NP This e-mail may contain personal views which are not the views of the BBC. ___ 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] C API doc fix
On 29 Sep 2005, at 12:06, Steven Bethard wrote: > On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote: > >> Yesterday I ran into a bug in the C API docs. The top of this page: >> >> http://docs.python.org/api/unicodeObjects.html >> >> says: >> >> Py_UNICODE >> This type represents a 16-bit unsigned storage type which is >> used by Python internally as basis for holding Unicode ordinals. On >> platforms where wchar_t is available and also has 16-bits, Py_UNICODE >> is a typedef alias for wchar_t to enhance native platform >> compatibility. On all other platforms, Py_UNICODE is a typedef alias >> for unsigned short. >> > > I believe this is the same issue that was brought up in May[1]. My > impression was that people could not agree on a documentation patch. Would it help if I tried my hand at it? My impression so far is that extension coders should probably try not to worry about the size or content of Py_UNICODE. (The thread seems to have wandered off into nowhere again...) Py_UNICODE This type represents an unsigned storage type at least 16-bits long (but sometimes more) which is used by Python internally as basis for holding Unicode ordinals. On platforms where wchar_t is available and also has 16-bits, Py_UNICODE is a typedef alias for wchar_t to enhance native platform compatibility. In general, you should use PyUnicode_FromEncodedObject and PyUnicode_AsEncodedString to convert strings to/from unicode objects, and consider Py_UNICODE to be an implementation detail. robey ___ 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] Pythonic concurrency
> The problem with threads is at first glance they appear easy... Anyone who thinks that a "glance" is enough to understand something is too far gone to worry about. On the other hand, you might be referring to a putative brokenness of the Python documentation on Python threads. I'm not sure they're broken, though. They just point out the threading that Python provides, for folks who want to use threads. Are they required to provide a full course in threads? > ...which seduces many beginning programmers into using them. Don't worry about this. That's how "beginning programmers" learn. > The hard part is knowing when and how to lock shared resources... Well, I might say the "careful part". > ...at first glance you don't even realise you need to do this. Again, I'm not sure why you care what "glancers" do and don't realize. You could say the same about most algorithms and data structures. 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/archive%40mail-archive.com
Re: [Python-Dev] Pythonic concurrency
>> The hard part is knowing when and how to lock shared resources... Bill> Well, I might say the "careful part". With the Mojam middleware stuff I suffered quite awhile with a single-threaded implementation that would hang the entire webserver if a backend query took too long. I realized I needed to do something (threads, asyncore, whatever), but didn't think I understood the issues well enough to do it right. Once I finally bit the bullet and switched to a multithreaded implementation, I didn't have too much trouble. Of course, the application was pretty mature at that point and I understood what objects were shared and needed to be locked. Oh, and I took Aahz's admonition to heart and pretty much stuck to using Queues for all synchronization. It ain't rocket science, but it can be subtle. 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] Pythonic concurrency
On Mon, 2005-10-10 at 18:59, Bill Janssen wrote: > > The problem with threads is at first glance they appear easy... > > Anyone who thinks that a "glance" is enough to understand something is > too far gone to worry about. On the other hand, you might be > referring to a putative brokenness of the Python documentation on > Python threads. I'm not sure they're broken, though. They just point > out the threading that Python provides, for folks who want to use > threads. Are they required to provide a full course in threads? I was speaking in general, not about Python in particular. If anything, Python is one of the simplest and safest platforms for threading (thanks mostly to the GIL). And I find the documentation excellent :-) > > ...which seduces many beginning programmers into using them. > > Don't worry about this. That's how "beginning programmers" learn. Many other things "beginning programmers" learn very quickly break if you do it wrong, until you learn to do it right. Threads are tricky in that they can "mostly work", and it can be a long while before you realise it is actually broken. I don't know how many bits of other people's code I've had to fix that worked for years until it was run on hardware fast enough to trigger that nasty race condition :-) -- Donovan Baarda <[EMAIL PROTECTED]> ___ 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] C API doc fix
Robey Pointer wrote: > On 29 Sep 2005, at 12:06, Steven Bethard wrote: > > >>On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote: >> >> >>>Yesterday I ran into a bug in the C API docs. The top of this page: >>> >>> http://docs.python.org/api/unicodeObjects.html >>> >>>says: >>> >>>Py_UNICODE >>> This type represents a 16-bit unsigned storage type which is >>>used by Python internally as basis for holding Unicode ordinals. On >>>platforms where wchar_t is available and also has 16-bits, Py_UNICODE >>>is a typedef alias for wchar_t to enhance native platform >>>compatibility. On all other platforms, Py_UNICODE is a typedef alias >>>for unsigned short. >>> >> >>I believe this is the same issue that was brought up in May[1]. My >>impression was that people could not agree on a documentation patch. FYI, I've fixed the Py_UNICODE description now. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 10 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Pythonic concurrency
Skip, > With the Mojam middleware stuff I suffered quite awhile with a > single-threaded implementation that would hang the entire webserver if a > backend query took too long. I realized I needed to do something (threads, > asyncore, whatever), but didn't think I understood the issues well enough to > do it right. Yes, there's a troublesome meme in the world: "threads are hard". They aren't, really. You just have to know what you're doing. But that meme seems to keep quite capable people from doing things they are well qualified to do. > Once I finally bit the bullet and switched to a multithreaded > implementation, I didn't have too much trouble. Yep. > Of course, the application > was pretty mature at that point and I understood what objects were shared > and needed to be locked. Kind of like managing people, isn't it :-?. I've done a lot of middleware myself, of course. ILU was based on a thread-safe C library and worked with Python threads quite well. Lately I've been building UpLib (a threaded Python service) on top of Medusa, which has worked quite well. UpLib handles calls sequentially, but uses threads internally to manage underlying data transformations. Medusa almost but not quite supports per-request threads; I'm wondering if I should just fix that and post a patch. Or would that just be re-creating ZServer, which I admit I haven't figured out how to look at? 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/archive%40mail-archive.com
Re: [Python-Dev] Extending tuple unpacking
On 10/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not violate
DRY and is explicit about the error cases.
args = input.split()
try:
cmd = input.pop(0)
except IndexError:
cmd = ''
> def func(*args, **kwds):
> arg1, arg2, *rest = args # Unpack the positional arguments
rest = args# or args[:] if you really did want a copy
try:
arg1 = rest.pop(0)
arg2 = rest.pop(0)
except IndexError:
raise TypeError("foo() takes at least 2 arguments")
paul
___
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] Pythonic concurrency
> Yes, there's a troublesome meme in the world: "threads are hard". > They aren't, really. You just have to know what you're doing. I would say that the troublesome meme is that "threads are easy." I posted an earlier, rather longish message about this. The gist of which was: "when someone says that threads are easy, I have no idea what they mean by it." Perhaps this means "threads in Python are easier than threads in other languages." But I just finished a 150-page chapter on Concurrency in Java which took many months to write, based on a large chapter on Concurrency in C++ which probably took longer to write. I keep in reasonably good touch with some of the threading experts. I can't get any of them to say that it's easy, even though they really do understand the issues and think about it all the time. *Because* of that, they say that it's hard. So alright, I'll take the bait that you've laid down more than once, now. Perhaps you can go beyond saying that "threads really aren't hard" and explain the aspects of them that seem so easy to you. Perhaps you can give a nice clear explanation of cache coherency and memory barriers in multiprocessor machines? Or explain atomicity, volatility and visibility? Or, even better, maybe you can come up with a better concurrency model, which is what I think most of us are looking for in this discussion. Bruce Eckelhttp://www.BruceEckel.com mailto:[EMAIL PROTECTED] Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e" Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel Subscribe to my newsletter: http://www.mindview.net/Newsletter My schedule can be found at: http://www.mindview.net/Calendar ___ 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] PEP 3000 and exec
On 10/10/05, Christos Georgiou <[EMAIL PROTECTED]> wrote: > This might be minor-- but I didn't see anyone mentioning it so far. If > `exec` functionality is to be provided, then I think it still should be a > keyword for the parser to know; currently bytecode generation is affected if > `exec` is present. Even if that changes for Python 3k (we don't know yet), > the paragraph for exec should be annotated with a note about this issue. > But the PEP says that 'exec' will become a function and thus no longer become a built-in, so changing the grammar is not needed. -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] Fwd: defaultproperty
On 10/10/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote: > > > Never created for a reason? lumping things together for having the > > similar usage semantics, but unrelated purposes, might be something to > > avoid and maybe that's why it hasn't happened yet for decorators. If > > ever there was a makethreadsafe decorator, it should go in the thread > > module, etc. I mean, come on, its like making a module just to store a > > bunch of unrelated types just to lump them together because they're > > types. Who wants that? > > Like itertools? > > +1 for a decorators module. +1 from me as well. And placing defaultproperty in there makes sense if it is meant to be used as a decorator and not viewed as some spiffy descriptor. Should probably work in Michael's update_meta() function as well (albeit maybe with a different name since I think I remember Guido saying he didn't like the name). -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] Pythonic concurrency
Phillip J. Eby wrote: > What the GIL-ranters don't get is that the GIL actually gives you just > enough determinism to be able to write threaded programs that don't crash, > and that maybe will even work if you treat every point of interaction > between threads as a minefield and program with appropriate care. So, if > threads are "easy" in Python compared to other langauges, it's *because of* > the GIL, not in spite of it. Three cheers for the GIL! For the record, since I was quoted at the beginning of this subthread, *I* don't think threads are easy. But among all ways to handle concurrency, I just don't think they are so bad. And unlike many alternatives, they are relatively easy to get started with, and you can do a lot of work in a threaded system without knowing anything about threads. Of course, threads aren't the only way to accomplish that, just one of the easiest. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ 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] PEP 3000 and exec
>> This might be minor-- but I didn't see anyone mentioning it so far.
>> If `exec` functionality is to be provided, then I think it still
>> should be a keyword for the parser to know; currently bytecode
>> generation is affected if `exec` is present. Even if that changes
>> for Python 3k (we don't know yet), the paragraph for exec should be
>> annotated with a note about this issue.
Brett> But the PEP says that 'exec' will become a function and thus no
Brett> longer become a built-in, so changing the grammar is not needed.
I don't think that was the OP's point though it might not have been terribly
clear. Today, the presence of the exec statement in a function changes how
non-local load instructions are generated. Consider f and g with their
dis.dis output:
>>> def f(a):
... exec "import %s" % a
... print q
...
>>> def g(a):
... __import__(a)
... print q
...
>>> dis.dis(f)
2 0 LOAD_CONST 1 ('import %s')
3 LOAD_FAST0 (a)
6 BINARY_MODULO
7 LOAD_CONST 0 (None)
10 DUP_TOP
11 EXEC_STMT
3 12 LOAD_NAME1 (q)
15 PRINT_ITEM
16 PRINT_NEWLINE
17 LOAD_CONST 0 (None)
20 RETURN_VALUE
>>> dis.dis(g)
2 0 LOAD_GLOBAL 0 (__import__)
3 LOAD_FAST0 (a)
6 CALL_FUNCTION1
9 POP_TOP
3 10 LOAD_GLOBAL 2 (q)
13 PRINT_ITEM
14 PRINT_NEWLINE
15 LOAD_CONST 0 (None)
18 RETURN_VALUE
If the exec statement is replaced by a function, how will the bytecode
generator know that q should be looked up using LOAD_NAME instead of
LOAD_GLOBAL? Maybe it's a non-issue, but even if so, a note to that affect
on the wiki page might be worthwhile.
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] PEP 3000 and exec
My idea was to make the compiler smarter so that it would recognize
exec() even if it was just a function.
Another idea might be to change the exec() spec so that you are
required to pass in a namespace (and you can't use locals() either!).
Then the whole point becomes moot.
On 10/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> This might be minor-- but I didn't see anyone mentioning it so far.
> >> If `exec` functionality is to be provided, then I think it still
> >> should be a keyword for the parser to know; currently bytecode
> >> generation is affected if `exec` is present. Even if that changes
> >> for Python 3k (we don't know yet), the paragraph for exec should be
> >> annotated with a note about this issue.
>
> Brett> But the PEP says that 'exec' will become a function and thus no
> Brett> longer become a built-in, so changing the grammar is not needed.
>
> I don't think that was the OP's point though it might not have been terribly
> clear. Today, the presence of the exec statement in a function changes how
> non-local load instructions are generated. Consider f and g with their
> dis.dis output:
>
> >>> def f(a):
> ... exec "import %s" % a
> ... print q
> ...
> >>> def g(a):
> ... __import__(a)
> ... print q
> ...
> >>> dis.dis(f)
> 2 0 LOAD_CONST 1 ('import %s')
> 3 LOAD_FAST0 (a)
> 6 BINARY_MODULO
> 7 LOAD_CONST 0 (None)
> 10 DUP_TOP
> 11 EXEC_STMT
>
> 3 12 LOAD_NAME1 (q)
> 15 PRINT_ITEM
> 16 PRINT_NEWLINE
> 17 LOAD_CONST 0 (None)
> 20 RETURN_VALUE
> >>> dis.dis(g)
> 2 0 LOAD_GLOBAL 0 (__import__)
> 3 LOAD_FAST0 (a)
> 6 CALL_FUNCTION1
> 9 POP_TOP
>
> 3 10 LOAD_GLOBAL 2 (q)
> 13 PRINT_ITEM
> 14 PRINT_NEWLINE
> 15 LOAD_CONST 0 (None)
> 18 RETURN_VALUE
>
> If the exec statement is replaced by a function, how will the bytecode
> generator know that q should be looked up using LOAD_NAME instead of
> LOAD_GLOBAL? Maybe it's a non-issue, but even if so, a note to that affect
> on the wiki page might be worthwhile.
>
> 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/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] PEP 3000 and exec
On 10/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> This might be minor-- but I didn't see anyone mentioning it so far.
> >> If `exec` functionality is to be provided, then I think it still
> >> should be a keyword for the parser to know; currently bytecode
> >> generation is affected if `exec` is present. Even if that changes
> >> for Python 3k (we don't know yet), the paragraph for exec should be
> >> annotated with a note about this issue.
>
> Brett> But the PEP says that 'exec' will become a function and thus no
> Brett> longer become a built-in, so changing the grammar is not needed.
>
> I don't think that was the OP's point though it might not have been terribly
> clear. Today, the presence of the exec statement in a function changes how
> non-local load instructions are generated. Consider f and g with their
> dis.dis output:
>
> >>> def f(a):
> ... exec "import %s" % a
> ... print q
> ...
> >>> def g(a):
> ... __import__(a)
> ... print q
> ...
> >>> dis.dis(f)
> 2 0 LOAD_CONST 1 ('import %s')
> 3 LOAD_FAST0 (a)
> 6 BINARY_MODULO
> 7 LOAD_CONST 0 (None)
> 10 DUP_TOP
> 11 EXEC_STMT
>
> 3 12 LOAD_NAME1 (q)
> 15 PRINT_ITEM
> 16 PRINT_NEWLINE
> 17 LOAD_CONST 0 (None)
> 20 RETURN_VALUE
> >>> dis.dis(g)
> 2 0 LOAD_GLOBAL 0 (__import__)
> 3 LOAD_FAST0 (a)
> 6 CALL_FUNCTION1
> 9 POP_TOP
>
> 3 10 LOAD_GLOBAL 2 (q)
> 13 PRINT_ITEM
> 14 PRINT_NEWLINE
> 15 LOAD_CONST 0 (None)
> 18 RETURN_VALUE
>
> If the exec statement is replaced by a function, how will the bytecode
> generator know that q should be looked up using LOAD_NAME instead of
> LOAD_GLOBAL? Maybe it's a non-issue, but even if so, a note to that affect
> on the wiki page might be worthwhile.
Ah, OK. That makes more sense. For a quick, on-the-spot answer, one
possibility is for the 'exec' function to examine the execution stack,
go back to the caller, and patch the bytecode so that it uses
LOAD_NAME instead of LOAD_GLOBAL. Total hack, but it would work and
since 'exec' is not exactly performance-critical to begin with
something this expensive wouldn't necessarily out of the question.
But the better answer is we will just find a way. =)
-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] PythonCore\CurrentVersion
[Martin v. Löwis] >> What happened to the CurrentVersion registry entry documented at >> >> http://www.python.org/windows/python/registry.html >> >> AFAICT, even the python15.wse file did not fill a value in this >> entry (perhaps I'm misinterpreting the wse file, though). >> >> So was this ever used? Why is it documented, and who documented it >> (unfortunately, registry.html is not in cvs/subversion, either)? [Mark Hammond] > I believe I documented it many moons ago. I don't think CurrentVersion was > ever implemented (or possibly was for a very short time before being > removed). The "registered modules" concept was misguided and AFAIK is not > used by anyone - IMO it should be deprecated (if not just removed!). > Further, I believe the documentation in the file for PYTHONPATH is, as said > in those docs, out of date, but that the comments in getpathp.c are correct. It would be good to update that web page ;-) The construction of PYTHONPATH differs across platforms, which isn't good. Here's a key difference: playground/ someother/ script.py This is script.py: """ import sys from pprint import pprint pprint(sys.path) """ Suppose we run script.py while playground/ is the current directory. I'm using 2.4.2 here, but doubt it matters much. No Python-related envars are set. Windows (and the PIL and pywin32 extensions are installed here): C:\playground>\python24\python.exe someother\script.py ['C:\\playground\\someother', 'C:\\python24\\python24.zip', 'C:\\playground', 'C:\\python24\\DLLs', 'C:\\python24\\lib', 'C:\\python24\\lib\\plat-win', 'C:\\python24\\lib\\lib-tk', 'C:\\python24', 'C:\\python24\\lib\\site-packages', 'C:\\python24\\lib\\site-packages\\PIL', 'C:\\python24\\lib\\site-packages\\win32', 'C:\\python24\\lib\\site-packages\\win32\\lib', 'C:\\python24\\lib\\site-packages\\Pythonwin'] When PC/getpathp.c says: * Python always adds an empty entry at the start, which corresponds to the current directory. I'm not sure what it means. The directory containing the script we're _running_ shows up first in sys.path there, while the _current_ directory shows up third. Linux: the current directory doesn't show up at all: [playground]$ ~/Python-2.4.2/python someother/script.py ['/home/tim/playground/someother', '/usr/local/lib/python24.zip', '/home/tim/Python-2.4.2/Lib', '/home/tim/Python-2.4.2/Lib/plat-linux2', '/home/tim/Python-2.4.2/Lib/lib-tk', '/home/tim/Python-2.4.2/Modules', '/home/tim/Python-2.4.2/build/lib.linux-i686-2.4'] I have no concrete suggestion, as any change to sys.path will break something for someone. It's nevertheless not good that "current directory on sys.path?" doesn't have the same answer across platforms (unsure why, but I've been burned by that several times this year, but never before this year -- maybe sys.path _used_ to contain the current directory on Linux?). ___ 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] Extending tuple unpacking
Paul Du Bois wrote: > On 10/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: >>cmd, *args = input.split() > > These examples also have a reasonable implementation using list.pop(), > albeit one that requires more typing. On the plus side, it does not > violate > DRY and is explicit about the error cases. > > args = input.split() > try: > cmd = input.pop(0) > except IndexError: > cmd = '' I'd say you violated it right there ... (should have been):: args = input.split() try: cmd = arg.pop() except IndexError: cmd = '' FWIW, I've been +1 on * unpacking since I first saw the proposal, and have yet to see a convincing argument against it other than people wanting to stick the * anywhere but at the end. Perhaps I'll take the stdlib challenge (unfortunately, I have to travel this weekend, but I'll see if I can make time). Tim Delaney ___ 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] Extending tuple unpacking
Delaney, Timothy (Tim) wrote: > args = input.split() > > try: > cmd = arg.pop() ^^^ args ... > except IndexError: > cmd = '' Can't even get it right myself - does that prove a point? Tim Delaney ___ 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] PythonCore\CurrentVersion
> Suppose we run script.py while playground/ is the current directory. > I'm using 2.4.2 here, but doubt it matters much. No Python-related > envars are set. > > Windows (and the PIL and pywin32 extensions are installed here): > > C:\playground>\python24\python.exe someother\script.py > ['C:\\playground\\someother', > 'C:\\python24\\python24.zip', > 'C:\\playground', ... > When PC/getpathp.c says: > >* Python always adds an empty entry at the start, which corresponds > to the current directory. I believe it used to mean that literally '' was at the start of sys.path, but all the way back to 1.5.2 it seems that it really is the dirname of the script. Up to 2.2 it was as specifed in sys.argv, in 2.3 and later it was made absolute. > I'm not sure what it means. The directory containing the script we're > _running_ shows up first in sys.path there, while the _current_ > directory shows up third. That's strange - I don't see the current directory at all in any version. I get something very close to you when I have PYTHONPATH=. - although it then turns up as the second entry, consistent with the docs. Mark ___ 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] Pythonic concurrency
Bruce Eckel: > I would say that the troublesome meme is that "threads are easy." I > posted an earlier, rather longish message about this. The gist of > which was: "when someone says that threads are easy, I have no idea > what they mean by it." I think you are overcomplicating the issue by looking at too many levels at once. The memory model is something that implementers of threading support need to understand. Users of that threading support just need to know that concurrent access to variables is dangerous and that they should use locks to access shared variables or use other forms of packaged inter-thread communication. Double Checked Locking is an optimization (removal of a lock) of an attempt to better modularize code (by automating the helper object creation). I'd either just leave the lock in or if benchmarking revealed an unacceptable performance problem, allocate the helper object before the resource is accessible to more than one thread. For statics, expose an Init method that gets called when the application is in the initial one user thread state. > But I just finished a 150-page chapter on Concurrency in Java which > took many months to write, based on a large chapter on Concurrency in > C++ which probably took longer to write. I keep in reasonably good > touch with some of the threading experts. I can't get any of them to > say that it's easy, even though they really do understand the issues > and think about it all the time. *Because* of that, they say that it's > hard. Implementing threading is hard. Using threading is not that hard. Its a source of complexity but so are many aspects of development. I get scared by reentrance in UI code. 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] Pythonic concurrency
Ian Bicking wrote: > What the GIL-ranters don't get is that the GIL actually gives you just > enough determinism to be able to write threaded programs that don't crash, The GIL no doubt helps, but your threads can still get preempted between bytecodes, so I can't see it making much difference at the Python thought-level. I'm wondering whether Python threads should be non-preemptive by default. Preemptive threading is massive overkill for many applications. You don't need it, for example, if you just want to use threads to structure your program, overlap processing with I/O, etc. Preemptive threading would still be there as an option to turn on when you really need it. Or perhaps there could be a priority system, with a thread only able to be preempted by a thread of higher priority. If you ignore priorities, all your threads default to the same priority, so there's no preemption. If you want a thread that can preempt others, you give it a higher priority. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] Pythonic concurrency
On 10/10/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > I'm wondering whether Python threads should be > non-preemptive by default. Preemptive threading is > massive overkill for many applications. You don't > need it, for example, if you just want to use threads > to structure your program, overlap processing with I/O, > etc. I recall using a non-preemptive system in the past; in Amoeba, to be precise. Initially it worked great. But as we added more powerful APIs to the library, we started to run into bugs that were just as if you had preemptive scheduling: it wouldn't always be predictable whether a call into the library would need to do I/O or not (it might use some sort of cache) so it would sometimes allow other threads to run and sometimes not. Or a change to the library would change this behavior (making a call that didn't use to block into sometimes-blocking). Given the tendency of Python developers to build layers of abstractions I don't think it will help much. > Preemptive threading would still be there as an option > to turn on when you really need it. > > Or perhaps there could be a priority system, with a > thread only able to be preempted by a thread of higher > priority. If you ignore priorities, all your threads > default to the same priority, so there's no preemption. > If you want a thread that can preempt others, you give > it a higher priority. If you ask me, priorities are worse than the problem they are trying to solve. -- --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] PEP 3000 and exec
On 10/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > My idea was to make the compiler smarter so that it would recognize > exec() even if it was just a function. > > Another idea might be to change the exec() spec so that you are > required to pass in a namespace (and you can't use locals() either!). > Then the whole point becomes moot. I think that's a great idea. It goes a step towards a more analyzable Python, and really, I've never found a *good* use case for allowing this invisible munging of locals. I would guess that it would simplify the implementation, given that there are currently so many special cases around exec, including when used with nested scopes. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ 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] PEP 3000 and exec
Brett Cannon wrote: > But the better answer is we will just find a way. =) I think the best answer would be just to dump the idea of exec-in-local-namespace altogether. I don't think I've ever seen a use case for it that wasn't better done some other way. Most often it seems to be used to answer newbie "variable variable" questions, to which the *correct* answer is invariably "start thinking in Python, not bash/perl/tcl/PHP/ whatever." -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] PEP 3000 and exec
On 10/10/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > > But the better answer is we will just find a way. =) > > I think the best answer would be just to dump the idea of > exec-in-local-namespace altogether. I don't think I've > ever seen a use case for it that wasn't better done some > other way. > I agree that 'exec' could really stand to be tweaked. As it stands now it is nasty to deal with when it comes to program analysis. Anything that will make that easier gets my vote. -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] Pythonic concurrency
On 10/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I recall using a non-preemptive system in the past; in Amoeba, to be precise. > > Initially it worked great. > > But as we added more powerful APIs to the library, we started to run > into bugs that were just as if you had preemptive scheduling: it > wouldn't always be predictable whether a call into the library would > need to do I/O or not (it might use some sort of cache) so it would > sometimes allow other threads to run and sometimes not. Or a change to > the library would change this behavior (making a call that didn't use > to block into sometimes-blocking). I'm going to be giving a talk at OSDC (in Melbourne) this year about concurrency systems, and I'm going to talk a lot about the subtleties between these various non-preemptive (let's call them cooperative :) systems. I advocate a system that gives you really straightforward-looking code, but still requires you to annotate the fact that context switches can occur on every frame where they might occur (i.e., with a yield). I've given examples before of my new 2.5-yield + twisted Deferred code here, but to recap it just means that you have to do: def foo(): x = yield getPage() return "Yay" when you want to download a web page, and the caller of 'foo' would *also* need to do something like "yay = yield foo()". I think this is a very worthwhile tradeoff for those obsessed with "natural" code. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ 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] Pythonic concurrency
Guido writes: > Given the tendency of Python developers to build layers of > abstractions I don't think [non-preemptive threads] will help much. I think that's right, although I think adding priorities to Python's existing preemptive threads might be useful for real-time programmers (yes, as machines continue to get faster people are writing real-time software on top of VMs). IMO, if one understands the issues of simultaneous memory access by multiple threads, and understands condition variables (and their underlying concept of mutexes), threads are pretty easy to use. Getting into the habit of always writing thread-safe code is a good idea, too. It would be nice if some of these programming environments (IDLE, Emacs, Eclipse, Visual Studio) provided better support for analysis of threading issues in programs. I'd love to have the Interlisp thread inspector for Python. I sympathize with Bruce's Java experience, though. Java's original threading design is one of the many misfeatures of that somewhat horrible language (along with lack of multiple-inheritance, hybrid types, omission of unsigned integers, static typing, etc.). Synchronized methods is a weird way of presenting mutexes, IMO. Java's condition variables don't (didn't? has this been fixed?) quite work. The emphasis on portability and the resulting notions of red/green threading packages at the beginning didn't help either. Read Allen Holub's book. And Doug Lea's book. I understand much of this has been addressed with a new package in Java 1.5. 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/archive%40mail-archive.com
Re: [Python-Dev] PythonCore\CurrentVersion
On Monday 10 October 2005 18:42, Tim Peters wrote: > never before this year -- maybe sys.path _used_ to contain the current > directory on Linux?). It's been a long time since this was the case on Unix of any variety; I *think* this changed to the current state back before 2.0. -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
[Python-Dev] problem with genexp
There's a problem with genexp's that I think really needs to get
fixed. See http://python.org/sf/1167751 the details are below. This
code:
>>> foo(a = i for i in range(10))
generates "NameError: name 'i' is not defined" when run because:
2 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_GLOBAL 1 (i)
9 CALL_FUNCTION 256
12 POP_TOP
13 LOAD_CONST 0 (None)
16 RETURN_VALUE
If you add parens around the code: foo(a = i for i in range(10))
You get something quite different:
2 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_CONST 2 ( at 0x2a960baae8, file "", line 2>)
9 MAKE_FUNCTION0
12 LOAD_GLOBAL 1 (range)
15 LOAD_CONST 3 (10)
18 CALL_FUNCTION1
21 GET_ITER
22 CALL_FUNCTION1
25 CALL_FUNCTION 256
28 POP_TOP
29 LOAD_CONST 0 (None)
32 RETURN_VALUE
I agree with the bug report that the code should either raise a
SyntaxError or do the right thing.
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] Extending tuple unpacking
Delaney, Timothy (Tim) wrote: > Paul Du Bois wrote: > > >>On 10/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> >>> cmd, *args = input.split() >> >>These examples also have a reasonable implementation using list.pop(), >>albeit one that requires more typing. On the plus side, it does not >>violate >>DRY and is explicit about the error cases. >> >> args = input.split() >> try: >>cmd = input.pop(0) >> except IndexError: >>cmd = '' > > > I'd say you violated it right there ... (should have been):: > > args = input.split() > > try: > cmd = arg.pop() > except IndexError: > cmd = '' > > FWIW, I've been +1 on * unpacking since I first saw the proposal, and > have yet to see a convincing argument against it other than people > wanting to stick the * anywhere but at the end. Perhaps I'll take the > stdlib challenge (unfortunately, I have to travel this weekend, but I'll > see if I can make time). > > Tim Delaney I'm +1 for some way to do partial tuple unpacking, yet -1 on using the * symbol for that purpose outside of functions calls. The problem is the '*' means different things depending on where it's located. In a function def, it means to group or to pack, but from the calling end it's used to unpack. I don't expect it to change as it's been a part of Python for a long time and as long as it's only used with argument passing it's not too difficult to keep straight. My concern is if it's used outside of functions, then on the left hand side of assignments, it will be used to pack, but if used on the right hand side it will be to unpack. And if it becomes as common place as I think it will, it will present confusing uses and or situations where you may have to think, "oh yeah, it's umm... unpacking here and umm... packing there, but multiplying there". The point is it could be a stumbling block, especially for new Python users. So I think a certain amount of caution should be in order on this item. At least check that it's doesn't cause confusing situations. I really would like some form of easy and efficient tuple unpacking if possibly. I've played around with using '/' and '-' to split and to partially unpack lists, but it's probably better to use a named method. That has the benefit of always reading the same. Also packing tuples (other than in function defs) isn't needed if you have a way to do partial unpacking. a,b,c = alist[:2]+[alist[2:]] # a,b,rest Not the most efficient way I think, but maybe as a sequence method written in C it could be better? Cheers, Ron ___ 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] Extending tuple unpacking
On 10/10/05, Ron Adam <[EMAIL PROTECTED]> wrote: > The problem is the '*' means different things depending on where it's > located. In a function def, it means to group or to pack, but from the > calling end it's used to unpack. I don't expect it to change as it's > been a part of Python for a long time and as long as it's only used with > argument passing it's not too difficult to keep straight. > > My concern is if it's used outside of functions, then on the left hand > side of assignments, it will be used to pack, but if used on the right > hand side it will be to unpack. And if it becomes as common place as I > think it will, it will present confusing uses and or situations where > you may have to think, "oh yeah, it's umm... unpacking here and umm... > packing there, but multiplying there". The point is it could be a > stumbling block, especially for new Python users. So I think a certain > amount of caution should be in order on this item. At least check that > it's doesn't cause confusing situations. This particular concern, I believe, is a fallacy. If you squint the right way, using *rest for both packing and unpacking is totally logical. If a, b, *rest = (1, 2, 3, 4, 5) puts 1 into a, 2 into b, and (3, 4, 5) into rest, then it's totally logical and symmetrical if after that x = a, b, *rest puts (1, 2, 3, 4, 5) into x. BTW, what should [a, b, *rest] = (1, 2, 3, 4, 5) do? Should it set rest to (3, 4, 5) or to [3, 4, 5]? Suppose the latter. Then should we allow [*rest] = x as alternative syntax for rest = list(x) ? And then perhaps *rest = x should mean rest = tuple(x) Or should that be disallowed and would we have to write *rest, = x analogous to singleton tuples? There certainly is a need for doing the same from the end: *rest, a, b = (1, 2, 3, 4, 5) could set rest to (1, 2, 3), a to 4, and b to 5. From there it's a simple step towards a, b, *rest, d, e = (1, 2, 3, 4, 5) meaning a, b, rest, d, e = (1, 2, (3,), 4, 5) and so on. Where does it stop? BTW, and quite unrelated, I've always felt uncomfortable that you have to write f(a, b, foo=1, bar=2, *args, **kwds) I've always wanted to write that as f(a, b, *args, foo=1, bar=2, **kwds) but the current grammar doesn't allow it. Still -0 on the whole thing, -- --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] problem with genexp
On 10/10/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > There's a problem with genexp's that I think really needs to get > fixed. See http://python.org/sf/1167751 the details are below. This > code: > > >>> foo(a = i for i in range(10)) > > generates "NameError: name 'i' is not defined" when run because: [SNIP] > If you add parens around the code: foo(a = i for i in range(10)) > You get something quite different: Do you mean having ``(foo(a = i for i in range(10))``? Otherwise I see no difference when compared to the first value. -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] problem with genexp
On 10/10/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 10/10/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > There's a problem with genexp's that I think really needs to get > > fixed. See http://python.org/sf/1167751 the details are below. This > > code: > > > > >>> foo(a = i for i in range(10)) > > > > generates "NameError: name 'i' is not defined" when run because: > [SNIP] > > If you add parens around the code: foo(a = i for i in range(10)) > > You get something quite different: > > Do you mean having ``(foo(a = i for i in range(10))``? Otherwise I > see no difference when compared to the first value. Sorry, I think I put it in the bug report, but forgot to add it here: >>> foo(a = (i for i in range(10))) 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] PythonCore\CurrentVersion
Fred L. Drake, Jr. wrote: > On Monday 10 October 2005 18:42, Tim Peters wrote: > > never before this year -- maybe sys.path _used_ to contain the current > > directory on Linux?). > > It's been a long time since this was the case on Unix of any variety; I > *think* this changed to the current state back before 2.0. Please check again: [GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/usr/lib/python23.zip', '/usr/lib/python2.3', '/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk', '/usr/lib/python2.3/lib-dynload', '/usr/local/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages/Numeric', '/usr/lib/python2.3/site-packages/gtk-2.0', '/usr/lib/site-python'] We still have the empty string in sys.path, and it still denotes the current directory. 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
