|
Yeah I agree, Python is by far my favourite language. It's concise yet readable. It's just a joy to work in, I love how the modules work, the duck typing is great, all in all I really like it. Well, everything except the GIL in CPython, which basically prevents Python from running on multiple cores concurrently. However, there's a great module called Parallel Python which lets you do just that.
|
# ¿ Nov 4, 2007 19:49 |
|
|
# ¿ Mar 28, 2024 18:15 |
|
Yeah, the CPython implementation has the GIL. It was discussed in the beginning of the thread. Basically good solutions if you want real threading are to use either ironpython or jython or a module like parallel python (which I really like and you should try it).
|
# ¿ Nov 14, 2007 01:05 |
|
Haha, found this PEP on reddit, laffed. http://www.python.org/dev/peps/pep-3117/
|
# ¿ Nov 26, 2007 22:25 |
|
I'm getting into pygame right now and I think it's pretty cool, although does anyone else think that the documentation is lacking? It just seems that the function descriptions aren't as clear as they could be and there's never any example of usage. For instance, there are key constans listen in the documentation for pygame.key but it doesn't say anywhere in exactly which namespace they are. I looked everywhere through the pygame.key namespace only to see that they're defined in the main module namespace.
|
# ¿ Nov 30, 2007 00:41 |
|
Here's a good post from a guy who extended a function in C and got it to run from 30 seconds to 0.7 seconds. Pretty cool. http://www.ginstrom.com/scribbles/2007/12/02/extending-python-with-c-a-case-study/
|
# ¿ Dec 3, 2007 11:55 |
|
Here's an interesting one. Do you guys think there's a way to pass data from decorators to the functions they're decorating without using those functions' call arguments or keyword arguments? I've given this some thought and I think there is no way, but if anyone can prove me wrong that sure would be great. If you could somehow manipulate the function's namespace before calling it or something, hmmm. Here's an example of what I'm trying to do. code:
I'm not trying to solve a particular problem here (although it would come in handy with something I'm working on, but it's fine without it too), I'm just generally wondering if there's a way to do that in the language. My bets are on "no".
|
# ¿ Jan 9, 2008 01:54 |
|
Yay, I found the answer! Just do code:
|
# ¿ Jan 9, 2008 02:28 |
|
Haha! Yes, clown coding is the best coding. Eh, it seems that this func_globals is not gonna work since it pollutes the global namespace and I don't want that. code:
I wonder if there's a way to just affect a function's local namespace?
|
# ¿ Jan 9, 2008 03:00 |
|
Thanks guys, I'm glad we had this talk about clowns!
|
# ¿ Jan 9, 2008 19:59 |
|
The reason I started thinking about this is because in a Django project I'm working on, I have this decorator which has really proven to be useful.code:
Now the thing is sometimes the view has to know what the permissions are (so for instance you don't see an `add issue` link if you don't have that permission) and so the database is queried twice for the same data, once in the decorator and once in the view. That's not a problem really because everything is properly indexed and runs fine and dandy, so it's more curiosity than anything else.
|
# ¿ Jan 9, 2008 20:45 |
|
Does anyone know if there's any plan to implement proper closures in Python? I don't follow python-dev or anything, maybe someone here is more into that scene. I've been playing around with Ruby and while I generally like how Python does stuff (list comprehensions, less syntax, functions are objects, everything is visible) better, I really like the closures in Ruby. I've noticed that closures in Ruby usually achieve three things, which are: 1. Iterators 2. Doing preliminary actions before a block and clean-up actions after it (for instance, opening and closing a file) 3. Passing behavior to functions (for instance, telling buttons what to do) And I can't shake the feeling that Python should have gotten something very, very similar. It's true that Python supports all these three things, but it uses three different language constructs to do so and passing behavior to functions is not really elegant. It does iterators with generators, so in Ruby you'd do, for instance code:
code:
code:
code:
code:
code:
code:
Now notice that Ruby achieves all these three things with a single language construct whereas Python uses three and the last one is a bit wonky. But there's a problem, because if you introduced closures like in Ruby, you'd have several ways of implementing with statements and iterators and that would be unpythonic or something. But the usefulness is evident and it would be really nice to have closures for doing stuff like in the third example. EDIT: Maybe something like code:
hey mom its 420 fucked around with this message at 11:49 on Jan 15, 2008 |
# ¿ Jan 15, 2008 11:45 |
|
Well, if I had everything figured out on this would it would already be submitted as a PEP You're right, there are tricks and things to watch out for with implementing closures like that, but I still feel it would be worth thinking out. You say that a whole slew of helper functions are involved in Ruby's closures, could you elaborate on that? I thought that some_collection.each in Ruby just iterates through the elements of the collection and yields the supplied block for every element, passing the element to the block. Also, what do you mean when you say that you don't know the underlying control flow? The block you supply to the function will be yielded once or many times, that's it. It's the same with Python's generators, it will yield the values it goes through but you don't know what control flow it uses to get those values. Personally I don't think we you should care about what kind of control flow the internals of a function use, I just want it properly encapsulated and to do what it says in the documentation. There's a PEP (342) that I'm going through and trying to wrap my head around, it seems to put on a whole bunch of methods to generators and makes yield behave differently depending on context (also it seems strange to me that in python, something that's called like 'yield val' and not 'yield(val)' returns a value) to achieve coroutines, anyone got any comments on this PEP?
|
# ¿ Jan 16, 2008 01:20 |
|
bitprophet: Yo that's way cool! Will it be aimed at intermediate or beginner users? If you ever need to test the book out on someone or something like that, let me know! A note to anyone who is using Mediatemple hosting - they're developing Django support right now and are looking for people who have gridserver accounts there to test it out. I have an account there so I signed up.
|
# ¿ Jan 23, 2008 20:58 |
|
In the app I'm working on, we got it organized like thiscode:
|
# ¿ Jan 24, 2008 02:12 |
|
That's a cool solution! I also had a similar problem where we were filtering issues in a bug tracking system and at first also has a big if tree, but then I refactored it into this bit of code: code:
The magic is in the last line, which takes the querystring, turns it into a dict and uses it as arguments for the filter method. So you can do any kind of filtering you want off the bat, for example: ?page=1&issue_type__slug=bug&issue_status__slug=accepted&completed=no
|
# ¿ Feb 8, 2008 22:10 |
|
Also, does anyone know how to switch databases on the fly in Django? Or if that's even possible. I need that because when unit testing, I supply a JSON fixture that the tests use as sample data. When the tests are run, a temporary database is created and used and destroyed after the tests are done. But I'd like to pull some data from the regular database in the tests. That's because we've moved some setting values from settings.py (in order not to clutter it up too much) to the database and it would be cool to get those settings in the tests because they reference folders on your machine and I want the tests to be portable across machines.
|
# ¿ Feb 8, 2008 22:15 |
|
How exactly is that variable global? Can someone please explain to me? I would have thought `value` is not put in the global namespace when doingcode:
|
# ¿ Feb 11, 2008 19:38 |
|
No Safe Word: Umm, could you perhaps provide a working example of how that works? Here's what my interpreter says: code:
code:
|
# ¿ Feb 11, 2008 21:00 |
|
Ah yeah, glad we got this cleared up. I knew about accessing variables from parent namespaces. They're planning to implement a keyword called nonlocal, which would allow you to alter parent namespaces, which I think is pretty cool but isn't as cool as real closures.
|
# ¿ Feb 11, 2008 21:30 |
|
Use r'\bword\b' or '\\bword\\b'
|
# ¿ Mar 2, 2008 00:57 |
|
Here's a cool thing I've just found out while doing some stuff for school. The zip function works as its own inverse. So you can do stuff like thiscode:
code:
code:
hey mom its 420 fucked around with this message at 17:45 on Mar 14, 2008 |
# ¿ Mar 14, 2008 17:41 |
|
Habnabit posted:
Yeah, that is the prefered usage but I don't think Jython supports that yet. Does anyone know if they'll be changing yield to a function in Py3k? It seems kind of silly not to, because they're already changing print to a function and now yield can give you a return value so writing foo = (yield value) instead of foo = yield(value) just seems kind of hackish and like it doesn't go along with the rest of Python.
|
# ¿ Mar 18, 2008 09:28 |
|
If you make helper functions just so they're used once, you can always cram them in a lambda if you want stuff in one line. So your example can become:code:
|
# ¿ Mar 18, 2008 19:33 |
|
Yeah, I'm all for readability and I'd suggest going that way too. It's the most important characteristic of code, apart from elegance. Make the code so people can read it first, then for computers. But he mentioned that he wants the code to be as short as possible, so that's why I posted that solution. Although that presents the question, why would anyone want shortness of code over readability, apart from maybe limited storage space, but I doubt that's the issue..
|
# ¿ Mar 18, 2008 20:04 |
|
Ech. Performance, schmerformance!
|
# ¿ Mar 18, 2008 21:00 |
|
I don't know if you're allowed to use it, but you can do this:code:
|
# ¿ Apr 3, 2008 08:11 |
|
Aha, well if you're doing that with a string, you can do it like this.code:
code:
|
# ¿ Apr 3, 2008 11:11 |
|
Here's an interesting way to split an integer into digits without converting to strings.code:
hey mom its 420 fucked around with this message at 12:22 on Apr 3, 2008 |
# ¿ Apr 3, 2008 12:04 |
|
lst
|
# ¿ Apr 3, 2008 16:39 |
|
Doing stuff like that is generally not cool. You're using exec, polluting your global namespace, etc. I don't know what you ultimately achieve here since you only gave us a part of the code, but why not use a dict? A dict is used to map keys to values and it seems like that's what you're doing here. So I'd prefer code:
code:
code:
|
# ¿ May 1, 2008 12:23 |
|
Ah, yeah, right, the str is for the exec. Anyway, if all the data that goes into exec is from within your system, you're technically safe. In your case, it's right there in the same script, hardcoded by you, so it comes from within your system. If data you put in exec comes from some untrusted source (like the user), then it's a vulnerability. The thing why it's bad to use exec generally is because you may one day decide that something that you hardcoded previously should come from the user and you may not notice that it later gets fed into exec. Putting stuff like that into the global namespace is not considered good practice, since that can easily lead to name mix-ups and it's best to have everything in the smallest scope that you need. True, the namespace is represented as a dict, but it's important what's in which dict and it's nice to have stuff nicely scoped. But if you really want to put those names in the global namespace, you could achieve the same functionality without using exec like so: code:
|
# ¿ May 1, 2008 13:13 |
|
The thing with for loops is that you specify which variable you want each element of the list you're iterating over bound too. So you could just as well docode:
|
# ¿ May 9, 2008 18:32 |
|
Yeah, he was on spot. Python has drivers for mostly any kind of SQL database and can interact with them easily. Also Django is a web framework for Python, which makes it really easy to make web sites and web applications that use databases and all the Python knowledge you have is of course of great use with Django. Python is so widespread and generally useful that you pretty much can't miss with Python for any kind of use, but especially for web and databases. Also Google's App Engine is Python. It's a hosting environment for web Python program's by Google, also very cool and hip right now.
|
# ¿ May 9, 2008 20:27 |
|
trycode:
Also, it's not cool to use dict as a variable name, since the aforementioned function is named that way. hey mom its 420 fucked around with this message at 23:08 on May 14, 2008 |
# ¿ May 14, 2008 23:05 |
|
Yeah it's really easy to make really powerful one liners with Python, especially with generator expressions and the itertools module. I admit I submit to the urge a bit too often. But when you're just out to quickly make some code to one-tiem calculate something you need, it's great. For instance, I had a file that had 1 line for every hour in year 2007 and each line had the level of the tide on the Adriatic sea coast at that hour. It took me just 5 lines to read the file and get a list that has 24 values, each representing the average tide level for the hour over a year.
|
# ¿ May 14, 2008 23:30 |
|
Yeah it's good practice to maximize generator use and minimize lists. Of course it's cool to use lists for stuff you know will be small, but it doesn't cost you anything to use generators and generator expressions, but you will save on memory space when the data sets get big.
|
# ¿ May 15, 2008 00:04 |
|
sum is a function that takes anything you can iterate over and gives you the sum of all the elements. You can iterate over a list, a generator, a file or something completely different. You could do this code:
code:
|
# ¿ May 15, 2008 01:12 |
|
As far as I understand it, % is not going away, but there will be a sort of templating mini language available for more advanced stuff. Although from my usage, I've never caught myself saying "Gee golly, I wish there was something more advanced than the % operator built right into Python!" because it, along with regexes, has suited all my string manipulating needs so far.
|
# ¿ May 21, 2008 14:08 |
|
Well you seem to have it solved quite nicely, maybe you could rewrite it like thiscode:
code:
|
# ¿ May 22, 2008 23:46 |
|
|
# ¿ Mar 28, 2024 18:15 |
|
Whoops, my bad! It seems that deleting normal functions also exhibits this behavior. I don't know why, but I thought that inside a function, the function name overshadowed the function name in the parent namespace or was set if it wasn't present. Most interesting indeed. Anyone have any ideas on how to get around this problem in normal functions? Something like code:
So anyway yeah, you could make this a lambda then, like so code:
|
# ¿ May 23, 2008 00:17 |