Re: Python programming books
John Bokma j...@castleamber.com wrote in message news:87oc63nvuo@castleamber.com... I also like the Python Essential Reference a lot. I'd second that. Python Essential Reference effectively documents the batteries included aspect of Python, using lots of good examples in a quite readable tome. -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message news:4d0aa5e7$0$29997$c3e8da3$54964...@news.astraweb.com... It doesn't look like you were learning Python. It looks like you were learning C with Python syntax :( True, although in many cases one has to interface to legacy C code where it'd be rather more code to start throwing exceptions left or right... since sooner or later those exceptions would still have to be turned into a single status (error) code! which all too often becomes: result = obj.myMethod(arg1, arg2) if result == good1: do_something_good() else: # assume result is bad1 handle_error1() This really isn't a bad way to go *if you weren't planning on spending the time to really, fully flesh out the individual error cases anyway.* I see this pretty often: Peple put in sophisticated exception handling infrastructure, but when an error actually occurs, all six dozen cases handled individually end up just printing some generic message and exiting the program anyway. In an ideal world all the error cases would do something smart, but pragmatically one has to balance how likely an error is to occur and how much damage it does with how much time you want to spend making a really smart error handler. or even: who_cares = obj.myMethod(arg1, arg2) do_something_good() Even this can be OK if do_something_good() behaves in a relatively benign fashion when feed gibberish. I mean, how many people actually check to see whether or not printf() succeeded, you know? But I would agree that often you see... who_care = obj.myMethod(arg1, arg2) do_something_really_dangerous_that_depends_on_the_success_of_myMethod() :-) Well, that's better, but still more like C rather than Python. Avoid the anti-pattern of returning in-band error codes. The main sticky point here is that what's an error vs. a warning or note (but not success) is often rather a grey area. E.g., Pyhton's open() raises an IOError is the file can't be opened, but in my mind that's still a common enough/expected occurrence that elevating its behavior to an exception is more a judgement call than something everyone would agree on. (On the other hand, trying to read or write to an un-opened file is now clearly in the realm of an error and deserves an exception.) ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Can PySerial's write method be called by multiple threads?
I have a multi-threaded application where several of the threads need to write to a serial port that's being handled by pySerial. If pySerial thread-safe in the sense that pySerial.write behaves atomically? I.e., if thread 1 executes, serport.write(Hello, world!) and thread 2 executes serport.write(All your bases are belong to us!), is it guaranteed that the output over the serial port won't mix the two together (e.g., Hello All your bases are belong to us!, world!) ? I looked at the source code, and the write method eventually boils down to calling an the OS's write function, which presumably ends up being a call to a C function. Given the global interpreter lock -- and particularly how C functions can't be interrupted by the Python interpreter at all -- it sure seems as though everything is copacetic here? If not I can just add a queue and have everything go through it, but of course I'd like to avoid the extra code and CPU cycles if it isn't at all necessary. Thank you, ---Joel Koltner -- http://mail.python.org/mailman/listinfo/python-list
Re: Can PySerial's write method be called by multiple threads?
Thomas Jollans tho...@jollybox.de wrote in message news:mailman.36.1282762569.29448.python-l...@python.org... I expect that it gives away the GIL to call the resident write() function, to allow other threads to run while it's sitting there, blocking. I haven't looked at the code, so maybe it doesn't hand over the GIL, but if it doesn't, I'd consider that a bug rather than a feature: the GIL shouldn't be abused as some kind of local mutex, and only gets in the way anyway. Ah, I expect you're correct. I'm still largely a Python newbie, and only know enough about things like the GIL to get myself into trouble. Speaking of the GIL, you shouldn't rely on it being there. Ever. It's a necessary evil, or it appears to be necessary. but nobody likes it and if somebody finds a good way to kick it out then that will happen. OK, but presumably I can't know whether or not someone who wrote a library like pySerial relied on it or not. Although I suppose this is really a documentation bug -- pySerial's documentation doesn't talk about multi-threaded access directly, although their minicom example does demonstrate it in action. Thanks for the help, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Can PySerial's write method be called by multiple threads?
Hi John,
John Nagle na...@animats.com wrote in message
news:4c75768a$0$1608$742ec...@news.sonic.net...
You don't need a queue, though; just use your own write function
with a lock.
Hmm... that would certainly work. I suppose it's even more efficient than a
queue in that the first thing the queue is going to do is to acquire a lock;
thanks for the idea!
def atomicwrite(fd, data) :
with lok :
fd.write(data)
Cool, I didn't know that threading.Lock() supported with! -- Just the other
day I was contemplating how one might go about duplicating the pattern in C++
where you do something like this:
{
Lock lok; // Constructor acquires lock, will be held until destructor
called (i.e., while lok remains in scope)
DoSomething();
} // Lock released
...clearly with does the job here.
---Joel
--
http://mail.python.org/mailman/listinfo/python-list
Do any debuggers support edit and continue?
Just curious... in Microsoft's Visual Studio (and I would presume some other tools), for many languages (both interpreted and compiled!) there's an edit and conitnue option that, when you hit a breakpoint, allows you to modify a line of code before it's actually executed. Does any Python debugger support this feature? Being an interpreted language it doesn't seem like it would necessarily be too onerous to support? It'd be quite handy in that, especially if you hit a breakpoint due to the interpreter throwing an error, you could fix just the line in question and keep going, rather than having to stop the entire program, fix the line, and then run again and potentially kill a bunch of time getting the program back into the same state. Thanks, ---Joel Koltner -- http://mail.python.org/mailman/listinfo/python-list
Re: Do any debuggers support edit and continue?
Terry Reedy tjre...@udel.edu wrote in message news:mailman.119.1273690025.32709.python-l...@python.org... CPython compiles Python code (a sequence of statements) to its private bytecode (a sequence of codes and operands) and then interprets the bytecode. So 'edit and continue' would have to recompile the statement and patch the result into the bytecode. I believe this is what, e.g., Visual Studio does with, e.g., C++ code -- it compiles the modified code and then patches the binary to call the new code as a subroutine or somesuch. Another problem is recovery of state. If an exception is raised in the middle of a statememt, there would need to be a means to roll back the state of objects and namespaces to what they were before execution of the statement started. So the interpreter would need to act like a transactional database, which is not trivial. Yeah, I can see this being challenging. I think it's pretty cool how some Python debuggers will allow you to use a shell with the context set to the current function or any of the calling functions higher up the call stack hierarchy as well. This would also slow normal execution, so it would have to be optional. That'd be a small price to pay. :-) (Visual Studio only lets you do this with unoptimized code...) If would definitely be nice. Perhaps $500,000 in funding would do the trick. Cool, if I win the lottery and add it to the worty causes list! :-) Thanks for the information, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Do any debuggers support edit and continue?
Phlip phlip2...@gmail.com wrote in message news:d580dece-bd42-4753-a0c6-783ce69b5...@m31g2000pre.googlegroups.com... People who need edit and continue probably need developer tests instead. You typically edit the test a little, run all the code, edit the code a little, run all the code, and integrate whenever the code's a little better and all the tests pass. I find myself making mistakes in typing the name of classes and/or methods when I'm first getting started with them (there are some thousands of them after all, and even of commonly used classes/methods you're probably talking upwards of a hundred), *particularly* when using libraries such as wxWidgets that use fancy imports that aren't correctly picked up by the code intelligence analyzers in, e.g., Komodo or Wing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Do any debuggers support edit and continue?
Phlip phlip2...@gmail.com wrote in message news:75c050d2-365e-4b08-8716-884ed5473...@k25g2000prh.googlegroups.com... On May 12, 12:44 pm, Joel Koltner zapwiredashgro...@yahoo.com wrote: Are you implying that you then run the code, and - after a handful of higher-level calls - control flow gets down to the lines you just typed, and the run fails because they are misspelled? Correct. The only fix is decoupling, and _expecting_ your first few debugger or test runs to fail. Well, sure, that is the current fix... but an edit and continue feature would make for a much faster fix. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Do any debuggers support edit and continue?
Phlip phlip2...@gmail.com wrote in message news:c014ae9f-99d8-4857-a3f7-e6ac16e45...@e34g2000pra.googlegroups.com... Are you implying, after an edit, you need to start a program again, then enter several user inputs, to navigate back to the place where you hit the syntax error? (WxWidgets noted - props!) Pretty much, yeah... Realistically, we're probably talking less than a minute each time, so objectively it's not really a big deal -- it's just different than what I'm used to so I'm noticing it more. :-) I guess what I'm realizing here is that one of the upsides of compiled languages is that they'll (usually) catch most typos before your program even runs! -- http://mail.python.org/mailman/listinfo/python-list
Re: Do any debuggers support edit and continue?
John Nagle na...@animats.com wrote in message news:4beb15c5$0$1634$742ec...@news.sonic.net... Having actually used LISP systems with edit and continue, it's a good thing that Python doesn't have it. It encourages a patch mentality, and the resulting code is usually disappointing. Hey, a lot of people would argue that Python's lack of strong typing and data/member protection (from one class to another) encourages sloppy programming too. :-) (Some people even figure that automatic garbage collection does so!) What the original poster seems to need is a global analysis tool that insures that all names used are defined. Like pylint. Sounds intriguing... I'll check it out; thanks! ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: len() should always return something
Dr. Phillip M. Feldman pfeld...@verizon.net wrote in message news:mailman.3699.1248490256.8015.python-l...@python.org... Here's a simple-minded example: ... This function works fine if xs is a list of floats, but not if it is single float. It can be made to work as follows: Wow, you could substitute Matlab for Python in your post and it'd still be just as good. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Q: Best book for teaching
Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote in message news:grhq75$eb...@lust.ihug.co.nz... I thought that a good introduction might be to show them how HTML works, and progress from there to embedding little bits of JavaScript. Nothing to do with Python I know, but might be a possibility. If you want to emphasize web usage, I'd be tempted to show them a bit of HTML and then introduce them to CGI-bin scripts... written in Python. Something like Django might be fun to show as well, although such full featured content management systems are really a course unto themselves. (And if you're used Python scripts on the server and played with, e.g., MySQL a little, it'll be clear that things like Django are just greatly expanded versions of what they're doing themselves.) ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Library for generating indicators and graphs for weather stations
Hello, Could someone suggest a Python library for generating the indicators and graphs that weather station software typically produces, e.g., similar to those seen here: http://www.weather-display.com/wdfull.html ... and here: http://www.weather-display.com/index.php ? I did stumble across the IaGraph package (http://www.johnny-lin.com/py_pkgs/IaGraph/Doc/index.html) -- which was even developed by a guy doing climate analysis -- but that package was designed for graphing results and hence doesn't solve the current [wind speed/direction/etc.] indicator problem. My goal here is to have my weather station upload its raw data to a commercial web server and then have a CGI Python script generate the actual web page to display that data. (Actually, my short-term goal is to just write a few Python scripts that feed the data to Weather Underground as this is much easier to do and WU alround makes nice graphs, but long term generating my own custom web pages would be fun...) But in any case, the idea is that I could feed some lists of data to a graphing widget or somesuch and be able to spit out PNGs or GIFs of the results for ready reference from an HTML file. Thank you, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Easy-to-use Python GUI
Thanks to everyone who responded; I'll be checking out the various toolkits people have listed! ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: SQL, lite lite lite
Gerhard Häring g...@ghaering.de wrote in message news:6rvgihf3je6...@mid.uni-berlin.de... Using an ORM when you don't grasp the relational model and/or the SQL query language is futile. You'd probably be surprised just how many people there are out there using SQLlite (and other databases) who have no more than a 5 minute introduction to relational databasess. See, you have tables, and you can stick columns for various attributes, and then add records for rows, and if you make multiple tables you specify which attribute becomes a 'key value' to find the corresponding record in another. Have fun! That's probably the case for many other abstraction layers, too. GUIs come to mind... -- http://mail.python.org/mailman/listinfo/python-list
Easy-to-use Python GUI
Is there an easy-to-use, function-based cross-platform GUI toolkit for Python out there that's a little more sophisticated than EasyGui? EasyGui looks good, but it's a little more restrictive than what I'd like to have, yet I'm (stubbornly :-) ) resistant to stepping up to a full service GUI toolkit such as pyGTK or wxPython where it's all about event loops and callbacks and you need to start planning how the GUI affects the overall program flow rather than just using a forms (or Wizard)-type approach where you put up a few dialogs, users fill in some variables, and your program just sits around waiting until OK or Cancel is clicked. One approach that I like comes from SAX BASIC/WinWrap, which is more or less a clone of Microsoft's Visual BASIC for Applications, but they (apparently) wanted everything to still be human-readable, so they have a simple GUI (form) builder that generates code that looks like this: --- Begin Dialog UserDialog 850,497,Export Control ' %GRID:10,7,1,1 GroupBox 20,7,360,217,Drill File Generation,.GroupBox1 CheckBox 40,35,130,14,Output drill file(s),.genDrill Text 40,63,270,28,Identify via layers as any that contain this text in their names:,.Text TextBox 40,98,220,21,.viaLayerName Text 40,140,100,14,Output method:,.Text8 DropListBox 160,140,180,21,DrillStyle(),.drillStyle Text 40,175,130,28,Select drill table units:,.Text2 ListBox 200,175,120,28,unitNames(),.unitName OKButton 310,469,90,21 CancelButton 410,469,90,21 End Dialog ' GUI builder generates or modifies everything above, but can also be edited by hand ' You write the following code... Dim dlg As UserDialog dlg.genDrill = 1 ReDim DrillStyle(1) DrillStyle(0) = All Via Layers In One File DrillStyle(1) = One File Per Via Layer dlg.drillStyle = 1 func=Dialog(dlg) --- This is pretty darned easy for me understand and modify either by hand or with the GUI builder. Still, it's quite powerful, since it supports all the common GUI elements (text, group boxes, checkboxes, drop-down lists, text boxes, buttons, etc.). This is about the level of sophistication I'm looking for. Anything like this for Python? Thanks, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: One step up from str.split()
Sion Arrowsmith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] What's wrong with sys.argv ? Mainly that it doesn't exist. :-) The example was slightly contrived -- I'm really dealing with commands interactively entered within a program in response to raw_input(), although the format of the commands is meant to be consistent with command-line usage. (A real command, for instance, would be something like this: load my firmware file.bin .) I ended up using shlex.strip() -- works great! ---Joel -- http://mail.python.org/mailman/listinfo/python-list
One step up from str.split()
I normally use str.split() for simple splitting of command line arguments, but I would like to support, e.g., long file names which-- under windows -- are typically provided as simple quoted string. E.g., myapp --dosomething --loadthis my file name.fil ...and I'd like to get back a list wherein ListEntry[3]=my file name.fil , but just running str.split() on the above string creates: ListEntry='myapp --dosomething --loadthis my file name.fil' ListEntry.split() ['myapp', '--dosomething', '--loadthis', 'my', 'file', 'name.fil'] Is there an easy way to provide just this one small additional feature (keeping quoted names as a single entry) rather than going to a full-blown command-line argument parsing tool? Even regular expressions seem like they'd probably be overkill here? Or no? Thanks, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: ��python in a nutshell��and��programming python��
yps [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] as a new learner of python,which book in python in a nutshell and programming python is more suitable? I don't have Python in a Nutshell, but let me ask... do you have a strong programming background in C++, Java, etc.? If so, you'll probably find Programming Python a little too basic. and recommend several books? For those with prior programming experience, I'd recomment Python: Essential Reference. Python Pocket Reference is worth having regardless of your background. A similar document is the freely download quick reference here: http://rgruet.free.fr/#QuickRef ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: php vs python
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think you are talking about something a little different than Arnaud. Ah, OK. Other old habits from people coming to Python are: using indexes where they are not needed, trivial getters and setters, putting *everything* into classes and every class into a module, and so on. Some of that is more political/policy than anything having to do with the language. Python likes to make it blatantly obvious that a lot of it is unnecessary, so it puts the control freak type of programmers on the defensive when, e.g., class variables and methods aren't private by default. (Guido's we're all conesenting adults here is of course a good response to this!) Another difference are internal versus external iterators. In Python you write the loop outside the iterable and pull the items out of it. In other languages (Ruby, Io, .) iterables do internal iteration and you give them a function where all item are pushed into one at a time. The Python method is -- IMO -- rather more powerful here, even if the whole protocol is somewhat less explciti than the Ruby/Io/etc. approach. What makes C++ a first class language? My somewhat arbitrary definition is something along the lines of a language with most all of the contemporary features expected of languages (e.g., old school procedural languages like C/Pascal/Fortran 77 don't count) that are targeting at writing everything from small utilities to programs of various sizes to full-blown operating systems. And did you quote first class for the same reason than I did? ;-) Probably... C++ is kinda like the McMaster-Carr catalog, whereas Python is a well-stocked hardware store with knowledgable salespeople. ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: php vs python
Arnaud Delobelle [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This is wrong, because if you know well one language only, you tend to think that the principles that underpin it are universal. So you will try to shoehorn these principles into any other language you use. Fair point, although I guess I was assuming the language you were good in was something that covers, say, 90% of contemporary programming practices, e.g., something like C++ : If you're truly good at C++ (and percentage-wise of all programmers, relatively few are), there are not many things that I'm aware of that are tremendously different in any other programming language. Function decorators from Java and some of the function programming stuff from Lisp, perhaps, but those are pretty small additions (well within the 10%). Perhaps I should reduce my claim to those good at programming in any first class language like C++ are generally going to write at least above-average code in any other language. :-) You may be great at building Turing machines. That doesn't make you a master of crafting lambda-expressions. Certainly the most important thing for any programmer to know is where his skills lie and where he should purposely keep things braindead simple because he's more likely to introduce bugs by trying to be eloquent. I find that eloquent Python speakers often tend to write a for loop when mere good ones will try to stick a list comprehension in! This is the trap I refer to above -- beginning programmers are far more likely to mis-use more sophisticated language features than experienced programmers are. Heck, you see entire languages like Java built around such premises, that it's better to have a simpler language that's harder to mis-use than a more sophisticated one that could be readily abused. C++ is perhaps the ultimate anything goes langauge -- tons of power and sophistication, very little nannying. Python has its own philosophy, of course, although at times it's somewhat arbitrary, e.g., for explicit is better than implicit -- sure, fine, but of course only applied to things that we haven't already decided should be implicit! Something like Python iterators are not at all explicit/obvious, for instance, to someone coming from, say, a Visual BASIC background... although I suppose they're still a lot simpler than, e.g., C++ scoping rules for name resolution. ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: php vs python
Ethan Furman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jerry Stuckle wrote: As I've said before - good programmers can write good code in any language. So... an eloquent speaker of English is also an eloquent speaker of Spanish/French/German? There's potentially a large difference between a good speaker of English/German/etc. vs. eloquent. I'd tend to agree with Jerry that if you can write good code in one language, you can in pretty much any other as well... but that doesn't imply you're necessarily eloquent in any languages. :-) Eloquence is nice, but eradicating bad code in this world is about a million times more important than attempting to move people from good code to eloquent code. To be Pythonic here, eloquent code would perhaps often have clear, clean list comprehensions used when good code would use a for loop but still be easy to follow as well and perfectly acceptable in the vast majority of cases. -- http://mail.python.org/mailman/listinfo/python-list
Weird exception in my, um, exception class constructor
I have a generic (do nothing) exception class that's coded like this: class MyError(exceptions.Exception): def __init__(self,args=None): self.args = args When I attempt to raise this exception via 'raise MyError' I get an exception within the MyError constructor __init__ as follows: Traceback (most recent call last): [lines deleted] File c:\Documents and Settings\Joel.Kolstad\My Documents\Python\ MyStuff.py, line 7, in __init__ self.args = args TypeError: 'NoneType' object is not iterable Ummm... why should 'args' have to be iterable anyway? I don't understand what's going on here? Could someone help me with this? I've found empirically that I can write: if args self.args = args ...and everything *appears* to work OK, but I'd really like to know what the core problem is. Thank you, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Weird exception in my, um, exception class constructor
Hi Arnaud, Arnaud Delobelle [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That's because the class 'Exception' defines a descriptor 'args' which has to be a sequence. Ah, thanks. I was following the example in Beazley's book and should have dug into the actual documentation a bit more. OTOH you could just take advantage of Exception.args: class MyError(Exception): pass Sounds good to me. I take it that, if I don't inherit from Exception, various expected behaviors will break? (This is what Beazley suggests...) ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Weird exception in my, um, exception class constructor
Paul Hankin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Did you actually write self,args = args? (looks at source code) [EMAIL PROTECTED] Why, yes, yes I did! Thanks for catching that... -- http://mail.python.org/mailman/listinfo/python-list
Reloading function obtained via 'from xxx import yyy'
How do I get Python to correctly re-load this function definition? In test.py: def testFunc(): print 'My testFunc!' I execute... from test import testFunc testFunc() My testFunc! Fine... now I change test.py to: def testFunc(): print 'Modified testFunc!' ...and I'd like to reload testFunc. How do I do so? 'from test import testFunc' keeps the old definition around, and 'reload test' of course doesn't work becayse I didn't use 'import test' in the first place. Thanks for the help, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Reloading function obtained via 'from xxx import yyy'
Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Try all three of them, in sequence: Thanks, will do. If you absolutely don't want to import test, write I can live with the import, I just don't want to have to type out the full names all the time. ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Producing multiple items in a list comprehension
Is there an easy way to get a list comprehension to produce a flat list of, say, [x,2*x] for each input argument? E.g., I'd like to do something like: [ [x,2*x] for x in range(4) ] ...and receive [ 0,0,1,2,2,4,3,6] ...but of course you really get a list of lists: [[0, 0], [1, 2], [2, 4], [3, 6]] I'm aware I can use any of the standard flatten bits of code to turn this back into what I want, but I was hoping there's some way to avoid the lists of lists generation in the first place? A slightly similar problem: If I want to merge, say, list1=[1,2,3] with list2=[4,5,6] to obtain [1,4,2,5,3,6], is there some clever way with zip to do so? Thanks, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Producing multiple items in a list comprehension
Peter Otten [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A slightly similar problem: If I want to merge, say, list1=[1,2,3] ... items = [None] * 6 items[::2] = 1,2,3 items[1::2] = 4,5,6 items [1, 4, 2, 5, 3, 6] Thanks Peter, that's pretty clean -- I like it! -- http://mail.python.org/mailman/listinfo/python-list
Re: Producing multiple items in a list comprehension
inhahe [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] i figured out a solution sum([x,2*x] for x in range(4)],[]) #not tested Nice... thanks; I probably had seen code using 'sum' to flatten but hadn't actually understood how it worked. After playing around some it's now clear... (Add one more opening bracket to your solution to make the interpreter happy -- I know you know this and it was missed only due to not actually trying it ought) ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Producing multiple items in a list comprehension
Hi Marc, Marc Christiansen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm not sure I would recommend it, but try: [v for x in range(4) for v in (x, 2 * x)] That certainly works... and it almost seems like a bit less of a hack (if perhaps somewhat harder to read) than the sum approach to flattening? A similar solution as above should work. This is what I came up with: list1=[1,2,3] list2=[4,5,6] [j for (i,m) in enumerate(list1) for j in (m,list2[i])] [1, 4, 2, 5, 3, 6] Not exactly clean due to having to enumerate list1 to get the index for list2. There may be a better method, of course -- so far I like Petter Otten's approach. Thanks for the help, ---Joel -- http://mail.python.org/mailman/listinfo/python-list
