|
deimos posted:Yeah but what happens if you call foo(clowns=20)? It prints 1, because foo.clowns is an attribute on the function object and clowns is a parameter. Kind of the difference between "clowns" and "self.clowns" in a method.
|
# ? Jan 9, 2008 17:25 |
|
|
# ? May 13, 2024 07:03 |
|
Thanks guys, I'm glad we had this talk about clowns!
|
# ? Jan 9, 2008 19:59 |
|
code:
e: the decorator with args decorator is the first hit from google, an old ASPN classic. Quite useful. e2: of course this means you can modify these function properties outside of the function call foo.lemons = "soup";foo(), which may or may not be desirable, but just because you have a scab doesn't mean you have to pick at it. Lonely Wolf fucked around with this message at 20:34 on Jan 9, 2008 |
# ? Jan 9, 2008 20:21 |
|
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 |
|
Lord Uffenham posted:You know, this could be generally useful. All right, let's nip this in the bud now. It was fun to speculate, but this has got to stop. All you're doing here is sticking the variables "clowns" and "lemons" into a namespace. In order to actually use them, the function needs to expect to find them in that namespace. We're using the function object itself as a namespace, because it's "convenient" - it seems like the function's code and the function object should be linked. But they're not actually linked in this way: the function's code is actually looking up the object it's attached to by name in the module's global namespace ("foo"). That's why we need to do the weird tricks with assigning to function name in the wrapper. If all you want is to add some bindings to a namespace that's looked up by name, might as well just create one explicitly. code:
If the problem is that you're trying to conform to an existing interface, so you have to pass information to the function through another channel, making a class (again, an explicit namespace) with a __call__ method would be better. People expect to find data members in classes - trying to set them on the function directly is just confusing. code:
(Notice I didn't do any tricks with keyword arguments in Foo.__init__. That's because knowing that init expects clowns and lemons is useful information, so it shouldn't be hidden away. Adding some default values might be good, though.)
|
# ? Jan 9, 2008 20:54 |
|
There are few cases I can think of where the decorator would be useful. If you need a C-style static variable or a simple singleton, it's your man. Otherwise a class is certainly more useful. I don't think it seems too magical or hackish, but then again half the fun I have in python (or any language) is just playing around with the internals and making it do things it wasn't meant to, so my point of view is a bit skewed. I couldn't recommend using it in a large project where its behavior may come as a surprise, or a multithreaded one where its behavior could degrade randomly, but for something small or one-off it's definitely less verbose; and, at any rate, easily refactored into a proper class come maintenance time. At the very least, it's something we can drop into our stupid python tricks bag.
|
# ? Jan 9, 2008 22:06 |
|
(Seperate issue, so seperate post) Has anyone had any experience with Pylons? I haven't done any web work, and I have some time off and lessened work load, so I'd like to play around with something. Django et al seem too straight-jackety. I don't really want to do anything with it, and am happy to just play around in its undocumented internals for fun, but if anyone has comments, criticisms, or tips about it I'd be happy to hear them.
|
# ? Jan 9, 2008 22:14 |
|
Lord Uffenham posted:I couldn't recommend using it in a large project where its behavior may come as a surprise, or a multithreaded one where its behavior could degrade randomly, but for something small or one-off it's definitely less verbose; and, at any rate, easily refactored into a proper class come maintenance time. What I worry about is unintended side effects from using the function name lookup - what if that behaviour changes between Python versions, or breaks something we haven't tested? If you're just using it once, my solutions no longer than your solution. If you're using the decorator many times, it's the same as abstracting some of the behaviour into a base class (in which case using a bundle of kwargs would be justified). At this point, it's basically 3 lines instead of 2 to define a function ("class Foo: / def __call__: / body" instead of "@decorator / def foo: / body").
|
# ? Jan 9, 2008 22:25 |
|
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 |
|
Bonus posted:Does anyone know if there's any plan to implement proper closures in Python? No. No plans. Guido hates lambda, and thinks that explicitly writing out functions is better. quote:
This is not an example of iterators in the sense that python uses them. An interator in python is a simplified generator. Something that returns each element in order. This is an example of using closures to implement control flow structures. I think you meant iteration rather than iterators. The same ruby code in python would be more like this: code:
I'm sure a smarter compiler might be able to remove some of this, but that requires some very clever typing. quote:Now notice that Ruby achieves all these three things with a single language construct And a whole slew of helper methods. I would argue that it isn't a simple language construct, as you don't know the underlying control flow. You rely on the implementation of the helper methods and hope they match. Every class is free to re-implement the control flow as it sees fit. It isn't necessarily a good thing to achieve three different structures with one, when they are different things. quote:But the usefulness is evident and it would be really nice to have closures for doing stuff like in the third example. The usefulness is saving a few lines of typing out an explcit function. See the 'Guido hates lambda' again. quote:EDIT: Maybe something like How do you pass more than one closure? (Special cases are not popular in python) Why would you call it yield or even similar to yield in python when yield is used to return a value, not yield control flow to a function. So, you would need a different name to the ruby construct. Would you also implement hasblock in python too ? Or would you have special syntax for defining a function that accepts a block. I'm not against closures per se, or against extending python's lambda construct to be more powerful, but it is hard to do so and maintain the spirit of python.
|
# ? Jan 15, 2008 13:03 |
|
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 |
|
To make the distinction more clear: In the python, the iterator either decides to return a value or not return a value. In ruby, the iterator decides to run the body or exit. This makes it hard to specify what to do at the end of the values. To give an example of python that is not so obviously translated to ruby. code:
I am not sure how this would work with ruby, but I assume you could do something with exceptions, or introduce new syntax to pass another closure, but would this then be for all method calls? Would you have to introduce a new haselse operator too ? In the end, although you can express one as the other, the implicit nature of ruby contains a lot of special cases, which I do not think is the right approach for python. I'll admit I don't like thinking in terms of closure passing for control flow, and I really don't like the implicit passing either. It's a very personal objection. Python already has it's own syntax for iteration and the with statement. The real problem is passing functions as arguments, so instead of trying to implement anonymous functions, I think we should try to name named functions less cumbersome. As a suggestion to your syntax, I propose the following: code:
code:
So, things like button would be defined: code:
You only have to name the function once. By naming the functions passed you can have more than one, and it also allows you to pass these functions as named values, using the existing **args mechanism. The new scope for the call means that it does not pollute the namespace. The downside is that you cannot do it as part of a larger expression.
|
# ? Jan 16, 2008 03:46 |
|
...
colonp fucked around with this message at 17:14 on Mar 8, 2014 |
# ? Jan 16, 2008 08:50 |
|
Hey guys, I've started learning Python as my start to beginning to learn programming, hopefully I'll have the staying power to learn a thing or two. Is it alright if I post really newbie questions here?
|
# ? Jan 16, 2008 09:34 |
|
LuckySevens posted:Hey guys, I've started learning Python as my start to beginning to learn programming, hopefully I'll have the staying power to learn a thing or two. Is it alright if I post really newbie questions here? Sure. I'd be glad to answer them if no one else does.
|
# ? Jan 16, 2008 10:13 |
|
colonp posted:It'd be great if someone could explain what exactly I'm supposed to do. You'll want to call find on the string searching for the character. If it finds none (find returns -1) then it found zero, so return the counter which is initialized to zero at the beginning. If it found one, increment the counter and do another find() except start right after where it found the last one. For example, if you have find 'a' in "aaba" you first call find on the string for a starting at position 0. Then, it finds one at position zero and returns 0 (the index of where it found it.) So, you increment your counter and call find with the starting index (third parameter) being 1 (0+1, where 0 is where it found the last instance.) This time it will return 1, so search starting at 2, which finds one at 3. It will return -1 after the last one is found, so use that -1 to signal when to return the counter to the calling procedure.
|
# ? Jan 16, 2008 10:17 |
|
...
colonp fucked around with this message at 17:14 on Mar 8, 2014 |
# ? Jan 17, 2008 07:07 |
|
Yeah, you're essentially doing the same problem as before but a different way (recursion) and the third optional parameter means that you don't need a helper function to do it, since you implicitly start at index=0 when you don't explicitly state what index you want to begin at. Here's the code I came up with, though untested it should work: code:
|
# ? Jan 17, 2008 09:24 |
|
FYI, Pycon registration is now open! http://us.pycon.org/2008/about/ I'll more than likely be going, but skipping the Tutorials day.
|
# ? Jan 21, 2008 04:08 |
|
From Simon Willison's blog, a public registry of Django users we Django folks should go register at.
|
# ? Jan 23, 2008 03:47 |
|
No idea how I missed that, thanks a lot! (edit: Oh, I didn't miss it, I just happened to see your post before checking my feed reader ) Neat site, despite getting a couple 500 errors trying to browse, and the screwed up tab order on the signup form. I envy those of you going to Pycon, I don't have the vacation time for it this year since I had to borrow for some important stuff that went down last year. Oh well. Hope you have fun! It's been made public as of a week ago (in Michael Trier's Jan 11th podcast), so I might as well toot the horn here: I and two other gents are working on a Django book it's been interesting so far and I hope we can get it out soonish and make it high quality as well. The framework is a moving target (for example, the method of generating forms from models in newforms changed without my noticing it about a month or so ago, and newforms itself is still relatively new and exciting...) which makes things difficult, but at least ours will be more up-to-date than the Apress book. Which is still a great book - anyone using Django should definitely grab a copy. bitprophet fucked around with this message at 06:07 on Jan 23, 2008 |
# ? Jan 23, 2008 05:49 |
|
LuckySevens posted:Hey guys, I've started learning Python as my start to beginning to learn programming, hopefully I'll have the staying power to learn a thing or two. Is it alright if I post really newbie questions here? Do the tutorial on the Python site in the standard documentation. Its a ripper. Any confusion over big-word stuff, pipe up in here. When you finish it, muck around with the modules (see module help on site), of for something more fun check out the pygame module, or if its your thing, something like Django (web stuff)
|
# ? Jan 23, 2008 19:10 |
|
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 |
|
Bonus posted: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! It's aimed at beginning and intermediate both, basically. We're providing a command line intro appendix, a chapter on Python (which is somewhat tailored for how it's used in Django, obviously) written by the author of Core Python, and some high level material on what Web development is all about from a backend perspective. So enough for a PHP dev to be able to pick up our book and finish it knowing how to use Django and use it well (not to mention that some of this will be of interest to people coming from the Java web world, Rails devs, and so forth). However, that's only part of the book, with the rest being just info about how Django works, best practices, example applications, and generally an attempt to cover the real-world applicable knowledge that the Apress book might not go into.
|
# ? Jan 23, 2008 22:41 |
|
Since we've got a bit of a Django thing going on, what's the best idea for how to structure templates within a project and its apps? I've been kind of using this structure, but it conflates project and app when I think they ought to be logically separate:code:
|
# ? Jan 24, 2008 00:52 |
|
In the app I'm working on, we got it organized like thiscode:
|
# ? Jan 24, 2008 02:12 |
|
As implied in your posts, there's two main template loaders - one global templates dir, or per-app templates dirs. The per-app setup is obviously preferable on the face of things because it means your apps are wholly self-contained; unfortunately it suffers from an odd problem which I don't know the answer to, but might investigate sometime as it's one of Django's biggest warts right now IMHO. The root of the issue is how we reference templates: relatively ("appname/templatename"), not absolutely ("/path/to/templatedir/templatename"). The root "namespace" that determines how templates are found depends on the loader used, a simple single folder in the global setup, or a concatenation of all the per-app folders in that scenario (technically, it looks in each app dir in order, but the effective result is the same). It's this implicit concatenation which is the problem - it means your template names must be 100% unique in order to be picked up correctly. If you have app1 and app2 with per-app template folders, and they both contain "index.html", then a template loader call to "index.html" will pick up the template whose app is listed first in your settings.py. So app2 is poo poo out of luck. You can get around this by adding a level of depth to your folders, i.e. "$myproject/app1/templates/app1/index.html", but then you're typing that extra "app1" all over the goddamn place and it just looks stupid (like how Django used to be about 2-3 years ago, before magic-removal reorganized things to be a lot more efficient). Or you can play policeman with your template names and make sure every app uses 100% unique names for all its templates, which is equally irritating/stupid. Hope that got the point across w/o being too verbose. If it wasn't obvious, I use the normal global-template-dir loader, with app subdirectories. It's sane, and in my case it's often necessary anyway because my projects tend to be very intermingled with lots of cross-referencing and shared templating, making the 'app' distinction largely just a way of organizing the models and view functions and less a collection of standalone applications. EDIT: I just scoured the docs, wiki and djangosnippets.org and nobody seems to have attacked this problem. There's a ticket in the tickets section (sadly a search for app_directories, the name of the loader in question, turns up hundreds of tickets and I was only able to search through the first, like, 200 before I got sick of it ) wherein someone asked for a change making the current app take precedence when using that loader. It was rejected largely because that behavior isn't ideal - you often want to include either other app's templates, or global templates, and that's not possible with such a loader. Malcolm also rejected the idea of making a third standard template loader implementing that behavior, which I can understand - they really don't like bogging down the core system with extra stuff unless it's absolutely necessary. However, I think if the problem can be solved with an extra loader, it would end up being used fairly often, which is why I'm surprised one doesn't exist on djangosnippets - I might try making one just to see. bitprophet fucked around with this message at 02:57 on Jan 24, 2008 |
# ? Jan 24, 2008 02:46 |
|
Having been turned on to Pygame in this thread and elsewhere, I've decided I really want to make a version of the board game Acquire. Before I even start, I'm wondering what I can do with my game if I make it using Pygame. Ideally I'd like to wrap it up into an installer/app for Windows/Mac/*nix/whatever that comes with its own copies of everything needed, so average Joe can download my game, set it up and then just run it. But everything I can find online tells me that for someone to play my game, they'd need to download Python (if they don't have it), Pygame and various other libraries. I don't know about you, but if I had to install that much crap to play a game, I'd never play anything. So does anyone know about distributing games made in Pygame in completely standalone packages? Can I do it?
|
# ? Jan 25, 2008 07:35 |
|
pokeyman posted:Having been turned on to Pygame in this thread and elsewhere, I've decided I really want to make a version of the board game Acquire. py2exe should be able to create a nice runnable distribution for Windows, and there is a py2app in the default Mac python 2.5 installation, if I remember correctly (but, that requires you to have a Mac to create it, and the files become insanely large (40+Mb), since you have to include the entire Python installation in the .app - why can't it be like py2exe and have python in a single 500kb .dll? ) For Linux, I'm not really sure, though...
|
# ? Jan 25, 2008 07:45 |
|
dorkanoid posted:For Linux, I'm not really sure, though... For Linux, Python will already be installed, and "install pygame" will be trivial (and nobody will care about needing to install it, since installing all dependencies separately instead of having multiple copies of things is the Linux Way).
|
# ? Jan 25, 2008 08:36 |
|
dorkanoid posted:py2exe py2exe is a bitch for pygame, though, by the way (there is a like pygame2exe or something, but it's hard to configure.)
|
# ? Jan 25, 2008 08:56 |
|
At work I use Visual Studio all day, so I'm getting to know it inside out. For my Django project at home I've used every type of IDE, and while I've come to appreciate WingIDE I still miss Visual Studio. Has anyone tried to Django using VS and IronPython (or IronPython Studio)? I'm sure I could edit files in it easily enough, but I'd want to be able to debug with it as well. I'll give it a go when I have time in a few days, but I wanted to see if others had tried it.
|
# ? Jan 25, 2008 10:04 |
|
Oh, OK, I thought I read that even after py2exe/py2app there were still some unresolved dependencies. Glad I'm wrong!
|
# ? Jan 25, 2008 17:41 |
|
Here's an interesting post from Guido flying around the 'tubes: http://mail.python.org/pipermail/python-dev/2008-January/076194.html I personally like it as a "hey that's neat for testing" idea - mock objects not withstanding. I like the followup from Robert Brewer where he saves an old copy of the method aside: http://mail.python.org/pipermail/python-dev/2008-January/076198.html
|
# ? Jan 30, 2008 14:08 |
|
Ugg boots posted:py2exe is a bitch for pygame, though, by the way (there is a like pygame2exe or something, but it's hard to configure.) How? Every time I've used it with pygame stuff, it just sort of magically works for me. There doesn't seem to be any extra configuation required.
|
# ? Jan 30, 2008 15:51 |
|
duck monster posted:How? Every time I've used it with pygame stuff, it just sort of magically works for me. There doesn't seem to be any extra configuation required. I was never able to get it work well/right and all I've read online is problems people have had with it. Maybe I was just retarded.
|
# ? Jan 30, 2008 20:48 |
|
I need some help with a small problem I'm having. I wrote my first python program ever to send cpu usage to an arduino for display on a vintage panel meter, just for fun. Occasionally it will quit with the error: C:\Python25>cpumon.py Traceback (most recent call last): File "C:\Python25\cpumon.py", line 35, in <module> idleTime = win32pdh.GetFormattedCounterValue(ProcCounter,format)[1] pywintypes.error: (-2147481642, 'GetFormattedCounterValue', 'No error message is available') Why and how can I simply ignore this and keep going? I know that's typically not a good idea but in this case it simply doesn't matter if it misses an update or something. Here's the code: code:
|
# ? Feb 1, 2008 23:57 |
|
w_hat posted:I need some help with a small problem I'm having. I wrote my first python program ever to send cpu usage to an arduino for display on a vintage panel meter, just for fun. Occasionally it will quit with the error: For why it's happening, you'd have to look up the docs of GetFormattedCounterValue. Here's how to swallor it: code:
|
# ? Feb 2, 2008 00:08 |
|
JoeNotCharles posted:
File "C:\Python25\cpumon.py", line 44 except pywintypes.error: ^ SyntaxError: invalid syntax Do I need to import something? Edit: Just kidding, I found it, thanks for the help. w_hat fucked around with this message at 00:27 on Feb 2, 2008 |
# ? Feb 2, 2008 00:18 |
|
|
# ? May 13, 2024 07:03 |
|
Nope, should be fine. (Don't actually put the "..." in - I just used that to mark code that I'd cut out.) Are you sure your indentation's correct? You might have to import pywintypes, but it would give a different error if that was the problem.
|
# ? Feb 2, 2008 00:24 |