Re: Python Packages : A looming problem? packages might no longer work? (well not on your platform or python version anyway)
On Wed, Apr 22, 2009 at 9:33 PM, David Lyon wrote: > Hi Steve, >>> Why should the package developer dictacte which python version the >>> package will run on ? >> >> Because they're the developer. Who else should decide what Python >> versions to support? > The developer shouldn't be making such decisions at all > What hardware or operating systems we run his/her programs on is > up to the real world to decide. > If you think about it logically... why are we even asking our > developers to even "build" their packages for specific python > versions in the first place? > They should just: Programmers need to know what they are programming for. Each version of the language changes things, and the old interpreters often cannot understand things introduced in later versions. There is no way to magically get code written for one version to work for a different version. Code written on any python less than 3 will work on any higher python version up to (but not including) 3, and the same is true for the 3 series, but going back down needs somebody to do the conversion, unless the programmer was meticulous in making it work on all versions. This problem of course, isn't just looming, it's been around for a while. Every time a new python version is introduced, there is chaos as some library writers move over, and some stay with the old, and others bend over backwards to support everybody. Unfortunately, it can't be helped, and the best people to handle the situation are the library authors themselves. The only way to prevent this would be to not release any new versions ever. In the case of python 3, there are probably some who would prefer to have no new versions ever, but no progress can be made without asking the question to move along with the moving target or stay comfortable. Now, a system to give developers access to more test configurations would help make it easier to support more systems. This is the approach of snakebite. But some giant network that automatically tests all of pypi on all configurations is infeasible, somehow automatically forcing libraries to work is not even possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
2009/4/18 Filip Gruszczyński : > Yep, I have heard a lot about test driven development. I am now > programming a lot using DJango and I would like to use its test > framework to try it. However, I have little experience with this (as > most people I know). I also have no idea, how to apply this, when I > write code heavily focused on user interface. There are many testing frameworks to choose from with regards to interface, but at least starting with unit tests (which don't need to interact with the interface) will still gain you something, and help guide the design probably a little better than interface tests at that. My style of TDD is to alternate somewhat between the code and the tests. When that idea pops into my head about how to do something, I will either write a test OR write the code to make it work, depending on what my inspiration is. If the inspiration is API related, then the test gets written first, because what is in my head are really interface stuff and not implementation. On the other hand, if my inspiration is code/implementation related, I will write the code. Afterward, I will switch and write the other piece, which sort of backs up whatever my decision was (or doesn't). I don't follow this exactly, it's just my general coding style when I am using tests. Sometimes I don't use tests at all (they aren't quite as helpful in game programming as in other domains), and in those cases I generally try to refactor or clean up my code before a script gets "too long", where too long means I am getting frustrated at not being able to find where to fix problems or add features fast enough. In practice, this usually means writing about 800-1000 lines of code in one script, and then exploding one script into several. > I thought, that prototyping is cool, especially with python, where you > can create something functional pretty quickly. But recently I was met > with a situation, when after writing 1k lines of prototype and then > writing main program > 3k lines I noticed, that there is something > really wrong with the design. It was then, that I started wondering: > maybe I should first prepare some good design documents, I don't know > some SAD or something. > It's pretty hard to design very much up front, because when you get into the code things change. Maybe if you do some coding and then start designing as you go to keep yourself on the right track. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Goes Mercurial
2009/4/3 Jeremiah Dodds : > > > On Thu, Apr 2, 2009 at 9:02 PM, andrew cooke wrote: >> >> Echo wrote: >> > 2009/4/2 Jeremiah Dodds >> > >> >> The one thing that makes me want to use git more than any other dvcs is >> >> that you don't have to create a new directory for branches. This may be >> >> possible in other dvcs's , but git is the only one I've seen advertise >> >> the >> >> capability. >> [...] >> > That is the main reason why I switched to git at my work. >> > As for the git rebase, I don't ever plan on using that 'feature'. Even >> > though I would rather have had GvR pick git, I think he did a good job >> > deciding. > It looks like basically the same thing is accomplishable in hg, but is a bit > discouraged (I am not experienced with hg, and haven't read the docs > thoroughly, so I could be off base here). In most (d)vcs's , there is > normally a one-to-one relationship between project branches and directories > on your filesystem. In git, there is normally a many-to-on relationship > between project branches and directories on your filesystem - branching is > cheap and easy, and you can branch for every little fix or feature you want > to do, keeping one directory with multiple logical development paths with > basically no pain. > > > -- > http://mail.python.org/mailman/listinfo/python-list > > I don't think it's discouraged at all. There are several ways to accomplish a similar workflow if you want a quick, short-lived branch. The ones I know of, are named branches, bookmarks, and mercurial queues. I have a hard time wrapping my head around what all of these (and git branching) mean, since a quick branch is something I rarely need in my personal development. The differences between each approach is very difficult for me to see. But they all let you have one set of files and work on disparate things at once to merge later. Queues (which is a patch stack) seem useful but also dangerous, since you can do a lot of switching back and forth without actually commiting. Since you can apply any of the queues to your working directory, they might work well for a short lived feature that you potentially put into a real branch or into the main if the feature is more complete and less experimental. Named branches work off of a changeset I believe. At any time you can rename the current branch, commit new stuff from that point in history, and you have a new branch; using the name to keep track of where you are. If you want to switch branches, you just update the working copy to be the new branch you want to work from. There are probably some advantages to how git handles things, considering this is the main feature I hear cited at something git does certifiably better, but I wouldn't know what that would be. Oh, and merc recently got a rebase as well, for good or ill. -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe automatic upgrades of a program while it is running, is that possible?
On Mon, Mar 2, 2009 at 6:56 PM, Maxim Khitrov wrote: > - Show quoted text - > On Mon, Mar 2, 2009 at 9:18 PM, William Heath wrote: >> Hi All, >> I am using py2exe to create a windows executable. I am curious if anyone >> knows a way to automatically upgrade a py2exe windows executable while it is >> running. Is that possible? If so how? If it isn't possible, what is the >> next best thing? Also, if it is not available using py2exe is it available >> in other languages/solutions your aware of? >> -Tim Here's what I did, which works really well. The main script imports other python modules which do the real work of the program. It is only a few lines long and looks something like this: import main main.run() There is more stuff there, imports etc to help py2exe find everything, but that's the basic idea. Then, to upgrade the program, all I have to do is replace the modules which are in a subfolder. (And be careful to reload them, which has its own considerations). I do some wonky stuff in my build script to delete my main modules from library.zip since its easier to replace them outside of that, you could also use the skip-archive option to not use the .zip file at all. You really can't replace an exe itself while its running, I would avoid that as much as possible. Workarounds to do this are highly prone to error. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple separate py2exe executables and library.zip
On Sun, Mar 1, 2009 at 8:35 AM, The Dude wrote: > Hello, > > Each invocation of py2exe creates an executable along with a number of > other files which need to be distributed with it, including library.zip. I > noticed that compiling different scripts creates different, and incompatible > library.zip-s. Suppose I need a directory that contains the result of > *separate* py2exe calls, then - how can there be a library.zip that fits > them all? > > Thanks & Bye, > > TD > > -- > http://mail.python.org/mailman/listinfo/python-list > > You can unpack each zip and then create one that has everything. A better option might be to work one of the executables to include all of the stuff, and then use its library.zip. Sometimes I have done this, by making an extra .py file which imports all of my other files. When I build the exe for this one, it will create the library.zip, and I just ignore the .exe. (In your build step you run this last). There might be better ways, but with py2exe I generally hack around problems and make my build process a bit more involved. (Often even calling out command line programs to do some of the work). -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I DRY the following code?
On Mon, Dec 29, 2008 at 6:13 PM, R. Bernstein wrote: > How do I DRY the following code? > > class C(): > > def f1(self, arg1, arg2=None, globals=None, locals=None): > ... unique stuff #1 ... > ... some common stuff #1 ... > ret = eval(args, globals, locals) > ... more stuff #2 ... > return retval Possibly make a separate method with the common stuff. Make each variant function call various other methods with the "different stuff" being different arguments to shared functions, or calling slightly different methods. Take the code one issue at a time, this seems complex enough that there is no easy, quick refactoring that can be done. Something like this is what I see, but it's hazy: def f1(self,args): ... unique stuff #1 self.commonstuff1() ret = self.myeval(args) self.commonstuff2() return retval Looking at the actual code, my thoughts are that you pick the most common base "run" type and stick with that, making other run types modify that. For instance, you could pass an evaluator function in to the base run() method, and call that, instead of having a separate case for exec or eval. runfunc would pass in the function itself as the evaluator. So it looks more like this: def run(blah, blah, BLAH, BLAH, evaluator, locals, globals): do much stuff evaluator(code,locals,globals) do much other stuff def runfunc(blah, func): run(blah, value_defined_for_runfunc, func, locals, globals) def runeval(blah): run(blah, value_defined_for_runfunc, eval, locals globals) The thing I don't like about this is it could very well make the main run function even hairier than it already is. But I don't think it has to be that way. This may not be the ideal solution either, if you can get a nice set of lower-level methods which each run method compose in different ways to produce the final result. > f1(...): > "Docstring f1" > c = C() > return c.f1(...) > > f2(...): > "Docstring f2" > c = C() > return c.f2(...) Why not just do either this: C().f2(..) where you need f2 Or make the function an argument: f(name): c = C() return getattr(c,name)() I'm not sure why you need the top-level functions though. If you really need them, and don't want to add an extra argument, I don't think there is a simpler way to do than you have. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Django/Turbogears too specific?
On Sun, Dec 21, 2008 at 11:41 AM, Gilles Ganault wrote: > Hi > > I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and > it seems like Django and Turbogears are the frameworks that have the > most momentum. > > I'd like to use this opportunity to lower the load on servers, as the > PHP application wasn't built to fit the number of users hammering the > servers now. > > I'm concerned, though, that these frameworks they may be too specific > to the tasks they were originally developped for (news articles, > AFAIK). Do you think I should just use eg. CherryPy and some basic > AJAX? > > Thank you for any feedback. > -- > http://mail.python.org/mailman/listinfo/python-list > No, they aren't very specific at all. Both frameworks allow configuration at nearly every level. The cool, slick admin interface might not be so useful depending on your application, but everything else has uses in just about any field. I only have experience with TG and cherrypy, TG for me is almost like cherrypy (I'm not sure if it still does, I've been out of the loop, but it used to use cherrypy under the hood), but a bit nicer to work with, especially if you have any AJAX. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, Dec 21, 2008 at 11:26 AM, r wrote: > I noticed when i mentioned "self" nobody wants to touch that subject. > There could be many reasons why... > > 0.) nobody but the 10 regulars i see here exists > 1.) nobody cares(doubt it) > 2.) nobody is brave enough to question it(maybe) > 3.) most people like to type self over and over again(doubt it) > 4.) most people here have given up on changing the BDFL's mind about > it. (good possibility) > 5.) this is a hot-button topic(no doubt in my mind!) It's a combination between (4) (5) and (6). 6 being, we have discussed "self" every week for the past 6 years, it hasn't changed yet, it's not going away, it's not a trivial "problem", deal with it. (0) is ridiculous, there are more than 10 respondents to this post alone. (1) - if nobody cared it wouldn't come up every week, but it's been discussed so much most are tired of it (2) - people question it all the time, usually people who are new to the language but not always. The discussion generally doesn't amount to anything (3) - It's not about wanting to type self over and over again, it's about being able to start with functions or start with classes, and easily refactor to the other way when needed; and never having a chance to wonder where a variable came from. There are ups and downs to self, it is generally more work to remove it than it is worth, what would the gain be? We'd be trading some ups and downs for some other ups and downs. And no, BDFL is not going to bend on self. He almost bent on the issue a few weeks ago, but his proposition merely changed some syntax - self was still there. On Sun, Dec 21, 2008 at 11:01 AM, Christian Heimes wrote: > We could have waited a few more months or even a few more years with a > 3.0 release. There is always - I repeat ALWAYS - work to do. For an open > source project like Python "release early, release often" works better. Good point, and I agree. It's too early for people to complain about python 3 being slow. It's also too both too late and too early to complain about things in python 3 that are thought of as a step backward. It's too late, because python 3 is out and it's already been changed! Things are not going to change back. Complaints are a bit useless at this point, except to let off steam. It's too early, because without using python3 in a major project, from the ground up, with the new features, the benefits or negatives for all of the changes cannot truly be known. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, Dec 20, 2008 at 10:15 PM, r wrote: > On Dec 20, 11:11 pm, walterbyrd wrote: >> On Dec 20, 5:05 pm, Roy Smith >> >> > He got really hung up on the % syntax. >> >> I guess it's good to know that there is, at least, one person in the >> world doesn't like the % formatting. As least the move was not >> entirely pointless. >> >> But, you must admit, of all the things people complain about with >> Python, the % formatting is probably one of the least common >> complaints. Complaints about Python's speed seem much more common. >> >> Yet, 3.0 makes the speed worse, and "fixes" a non-problem. A few points: 1) The new formatting is NOT the reason for the speed slowdown. So this change at least was a no cost change. No cost to interpreter speed, and no cost as it doesn't replace the old sprintf style. Of all the things to complain about in python 3.0, the format method is the silliest. 2) In my experience, major version changes tend to be slower than before. When a lot of things change, especially if very low-level things change, as happened in python 3.0, the new code has not yet went through many years of revision and optimization that the old code has. In my opinion, python 3 was rushed out the door a bit. It could have done with a few more months of optimization and polishing. However, on the other hand, it is going to take so long for python infrastructure to convert to python 3, that an earlier release makes sense, even if it hasn't been excessively polished. The biggest reason for the speed change is the rewritten stdio and unicode-everything. Hopefully this stuff can be improved in future updates. I don't think anyone WANTS cpython to be slower. -- http://mail.python.org/mailman/listinfo/python-list
Re: "as" keyword woes
On Wed, Dec 10, 2008 at 11:57 AM, Benjamin Kaplan
<[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Dec 10, 2008 at 12:22 PM, Patrick Mullen <[EMAIL PROTECTED]>
> wrote:
>>
>> I don't have a huge stake in this, but I wouldn't mind a change to
>> allow anything proceeding a "." or preceeding a "(" to not be
>> identified as a keyword. It is obvious to me a s a human reader that
>> something.if is quite a bit different than just a bare if. And as far
>> as parsing technology goes, isn't it supposed to go for the biggest
>> match first? I would not be for allowing bare keywords to be used in
>> the situations described above, but since we are so used to being able
>> to being able to have say, myclass.dir() or myclass.len() without them
>> overwriting the builtin functions, it makes sense to me to be able to
>> define a myclass.as() or myclass.with() without overwriting the
>> keywords. Though I know the semantics behind these two things are
>> very different, the rules I go through when reading the code are very
>> similar. The parser change might be a hassle, and it might not be
>> worth it at all of course, but from a conceptual point of view it is
>> simple. I mean, even now you can do class.__dict__["as"].
>
> so what happens here?
>
> if(some_condition()) :
> do_something(a)
>
> Yes, I know you don't need the parenthesis there in Python, but you still
> can use it.
>
>>
>> I guess I'm -1 for full PL/1 craziness, but +1 for qualified keyword
>> usage.
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
>
Right, I now see how this scenario is tricky. It could maybe be in
the form of " " but that starts
getting pretty complicated. Too tricky.
Following the period on the other hand still makes sense to me. It
makes sense in the nature of "I wouldn't mind seeing this added", but
I suppose it still might not make sense in the nature of "We should do
the work to make this a reality".
--
http://mail.python.org/mailman/listinfo/python-list
Re: "as" keyword woes
On Wed, Dec 10, 2008 at 6:57 AM, MRAB <[EMAIL PROTECTED]> wrote:
> Aaron Brady wrote:
>>
>> On Dec 9, 12:40 pm, MRAB <[EMAIL PROTECTED]> wrote:
>>>
>>> Aaron Brady wrote:
On Dec 9, 8:28 am, MRAB <[EMAIL PROTECTED]> wrote:
snip
>
> In some languages (I think Delphi is one of them - it's been a while!)
> some words which would normally be identifiers have a special meaning
> in
> certain contexts, but the syntax precludes any ambiguity, and not in a
> difficult way. "as" in Python was one of those.
> I certainly wouldn't want something like PL/I, where "IF", "THEN" and
> "ELSE" could be identifiers, so you could have code like:
> IF IF = THEN THEN
> THEN = ELSE;
> ELSE
> ELSE = IF;
> Seehttp://en.wikipedia.org/wiki/PL/I_(programming_language).
snip
That is, 'certainly' doesn't change the meaning of your statement
any. You wouldn't want it, but King George III didn't want the
American Revolution.
>>>
>>> It's called emphasis.
>>
>> I just take you to have meant, then, +1 on excluding keywords from
>> identifiers. You said it the long way though, so I thought I missed
>> something deeper, that didn't come across.
>>
> IIRC, most computer languages have an LL(1) grammar, which means that when
> they are parsed you need to look at only the next word. If you're about to
> parse a statement and the next word is "IF" then you know it's an
> IF-statement, if it's an identifier then it's either a call or an assignment
> statement (OK, you don't know exactly what kind of statement it is at that
> point, but it works out just fine!).
>
> In the example from PL/I, "IF" could be the start of an IF-statement "IF
> THEN" or an assignment statement "IF = ". It's a bit
> more tricky for the parser as well as the programmer.
>
> Life is easier if words having special meanings are reserved.
>
> However, that doesn't mean that all special words /must/ be reserved
> (pragmatism beats purity). Sometimes the syntax makes it clear and
> unambiguous, so you can get away with not making it a reserved word. The
> word "as" in Python doesn't need to be reserved because the syntax precludes
> ambiguity, but it's the only such word in the language, so it's just tidier
> to make it reserved too.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
I don't have a huge stake in this, but I wouldn't mind a change to
allow anything proceeding a "." or preceeding a "(" to not be
identified as a keyword. It is obvious to me a s a human reader that
something.if is quite a bit different than just a bare if. And as far
as parsing technology goes, isn't it supposed to go for the biggest
match first? I would not be for allowing bare keywords to be used in
the situations described above, but since we are so used to being able
to being able to have say, myclass.dir() or myclass.len() without them
overwriting the builtin functions, it makes sense to me to be able to
define a myclass.as() or myclass.with() without overwriting the
keywords. Though I know the semantics behind these two things are
very different, the rules I go through when reading the code are very
similar. The parser change might be a hassle, and it might not be
worth it at all of course, but from a conceptual point of view it is
simple. I mean, even now you can do class.__dict__["as"].
I guess I'm -1 for full PL/1 craziness, but +1 for qualified keyword usage.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Guido's new method definition idea
On Mon, Dec 8, 2008 at 12:55 PM, Arnaud Delobelle
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
>> class C:
>> def createfunc(self):
>> def self.func(arg):
>> return arg + 1
>>
>> Or, after the class definition is done, to extend it dynamically:
>>
>> def C.method(self, arg):
>> self.value = arg
>>
>> ...which would be the equivalent of the following:
>>
>> def method(self, arg):
>> self.value = arg
>> C.method = method
>
> What about the following then?
>
> functions = {}
>
> def functions['square'](x):
>return x*x
>
> def functions['cube'](x):
>return x**3
>
> --
> Arnaud
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Why not? "def ob.func" is fundamentally "def ob.__dict__["func"]" anyway.
I like this idea much better than the original proposal, even though
it is pretty much unrelated.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Strengths and weaknesses of Pygame vs. pyglet vs. PyOpenGL?
On Sun, Dec 7, 2008 at 4:43 PM, <[EMAIL PROTECTED]> wrote: > Trying to decide which to get started with. Can anyone suggest some > pros and cons to each of them? > > Would PyOpenGL be in the same camp as Pygame and pyglet? Do either of > Pygame or pyglet make use of PyOpenGL behind the scenes? > -- > http://mail.python.org/mailman/listinfo/python-list > PyOpengl - an opengl wrapper. Version 2 is written in c, version 3 instead uses ctypes Pyglet - an opengl + events/sound/etc wrapper written in ctypes pygame - an sdl wrapper for 2d rendering, sound, music, events, etc that can be used with pyopengl if 3d hardware support is desired. If you want to do 3d, your choice is basically pygame+pyopengl or pyglet. pyglet is nice because it comes with everything you need, versus pygame where you have to interact via pyopengl. Pygame +pyopengl2 is faster than pyglet or pygame+pyopengl3 becuase pyglet and pyopengl3 take a hit from ctypes. There is a project with pyopengl3 though to add some c code to speed things up, I think it works with numeric. Pyglet will be easiest to start with and use, it seems to be everyone's favorite choice these days. -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido's new method definition idea
>> Daniel Fetchinson wrote: >>> http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to- > stay.html >>> >>> The proposal is to allow this: >>> >>> class C: >>> def self.method( arg ): >>> self.value = arg >>> return self.value >>> >>> instead of this: >>> >>> class C: >>> def method( self, arg ): >>> self.value = arg >>> return self.value >>> I'd like this new way of defining methods, what do you guys think? I don't really like the proposed syntax any better than the old syntax. I certainly wouldn't use "def self." in any of my old code. I doubt I would use it in a new project were I to have the choice either. However, I don't really have a problem with other people liking it. the symetry of "def self.func(blah)==def func(self,blah)" and "ob.func(blah)==func(ob.blah)" is kind of neat. Could I do something like this: def a.add(b): return a+b Outside of a class? Of course then that makes you think you could do 5.add(6) or something crzy like that. (I mean, you can do (5).__add__(6) but that's something else entirely) -- http://mail.python.org/mailman/listinfo/python-list
Re: using exec() to instantiate a new object.
On Fri, Nov 7, 2008 at 2:23 PM, RyanN <[EMAIL PROTECTED]> wrote:
>
> to do this I tried:
>
>def addCountry(self,country_name):
># create an instance of country
>exec(country_name + "= country('" + country_name + "')")
># Add this new instance of a country to a list
>exec("self.countries.append(" + country_name + ")")
>
Don't use exec. It's quite dangerous, and in your case is making
things much more complex than necessary. A much simpler way to do
what you want:
def addCountry(self,country_name):
self.countries.append(country(country_name))
There is no need to bind the result of "country(country_name)" to a name at all.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Fri, Sep 26, 2008 at 1:11 PM, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Steven D'Aprano a écrit : >> >> On Fri, 26 Sep 2008 17:00:59 +0200, Bruno Desthuilliers wrote: >> >>> Patrick Mullen a écrit : >>>> >>>> Depending on the scale of the website I am making, how much I care >>>> about editing it in the future, and how much I just want to get >>>> something up, I will occasionally use php. And I am a self confessed >>>> php hater :) But it's generally the fastest way I know to get >>>> something up. So even terrible languages can have their uses! >>> >>> Sorry but I fail to see how it relates to the current thread ??? >> >> I think Patrick is responding to a comment from Tino Wildenhain: > > That didn't showed here (reading this from c.l.py via free.fr). Sorry. > >> [quote] >> Well then it still depends on the perception of "job done". For example >> PHP programmers would bet their soul that their language of choice is >> exactly the right one to "get the job done." [end quote] >> >> Patrick, you will cause much less confusion if you quote relevant parts of >> the text you are replying too. > > Indeed. At least it would have made clear (to me) there was something > missing in the thread... > -- > http://mail.python.org/mailman/listinfo/python-list Whoops, sorry for the confusion everyone. Usually I do keep the comments, don't know what happened there. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Depending on the scale of the website I am making, how much I care about editing it in the future, and how much I just want to get something up, I will occasionally use php. And I am a self confessed php hater :) But it's generally the fastest way I know to get something up. So even terrible languages can have their uses! -- http://mail.python.org/mailman/listinfo/python-list
Re: Wouldn't it be nice if this worked?
How about: class A: def add(self,x,y): return x+y class B(A): pass print B().add(1, 2) This also works: class A: def add(self, x, y): return x+y class B: pass B.add = A.add.im_func print B().add(1, 2) -- http://mail.python.org/mailman/listinfo/python-list
Re: Reasoning behind 'self' parameter in classes?
On Wed, Jul 30, 2008 at 12:27 PM, Robert Dailey <[EMAIL PROTECTED]> wrote: > > Given the code samples above, is there any technical reason why this cannot > be done? Thanks for the input guys, and thanks more over for keeping this > easy-going. > > -- > http://mail.python.org/mailman/listinfo/python-list > Well, the linked thread gives many reasons, but as mentioned it is a flamewar thread. Philosophically python is not an "object oriented" language per say, it has an object system, a not bolted on one I might add, but it doesn't force developers to use that methodology. You can be functional or procedural if you'd rather. Following this philosophy, when methods were designed, they were merely functions that got passed an instance as the first argument. The parser followed this design choice. As far as I understand it, the underlying method object is not different from a function argument, thus it cannot have any magic arguments built in. The only magic involved is the fact that the object, when calling a method, will pass its instance as the first argument. I don't believe there is any chance of this changing in python 3, python 4 is anyone's guess... This does allow some good things that come for free, like adding methods later, or changing functions into methods or methods into functions. If you start out developing a class, but feel a class is too bulky, you can delete the "class" line, dedent the methods, and have a set of functions instead for free. Or, if you have functions that are set up to take instances as their first argument already, you can bundle them up into a class very easily. If by "hack" you mean using features already available in the language to accomplish things, that kind of is what it is, and that's kind of what python is about. New syntax for a new feature is uncommon, but it happens. New syntax that breaks old code is very uncommon, and is only now coming out in python 3. And the biggest change in python 3 is to eliminate added syntax, such as print being a statement, and make the code reuse more python features rather than have every feature exist as an island. Print being a function, for instance, lets you use the same syntax for it that you use for other functions, making everything clearer and more unified. A common thing programmers might do when upgrading their code is to turn print statements into better logging functions - if print was a function in the first place this would be an easier task. Eliminating self doesn't accomplish much, and changes of this nature just don't get done without a good reason. It takes away something that might be annoying, but doesn't add anything. The benefits of changing have to be significant for a code change to break the existing syntax. Many people are upset even about some of the changes in python 3, that the benefits don't outweight the cost of change, and most of those changes are less damaging than playing around with the self businss would be :) So no, self not a mysterious thing that we should never question. Self is an understood thing that has been questioned very often (weekly, monthly) for many many years - there are not enough good reasons to bother with changing it, and there enough good reasons for it that it's best to keep it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Wed, Jun 11, 2008 at 12:28 PM, Russ P. <[EMAIL PROTECTED]> wrote: > > If Desthuilliers doesn't like my suggestion, then fine. If no other > Python programmer in the world likes it, then so be it. But do we > really need to get personal about it? Python will not be ruined if it > gets such a keyword, and Desthuilliers would be perfectly free to > continue using the leading-underscore convention if he wishes. Where > is the threat to his way of life? > Well, you have to understand that a lot of python programmers are refugees from the microsoft or sun worlds, where we were forced to do things a certain way, and often it was not in our opinion the best way, but there wasn't anything we could do about it. Some of these refugees are very experienced in that other world, and don't want to go back there. So proposing that python borrow these methods of control from the place we have fled from can feel threatening. Some people obviously take it more personally than others, but this is a general feeling a lot of python programmers share. Also I'm fairly certain you're not the first to mention this topic. Here's what the cookbook has to say: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/573442 Something like that is really your best bet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Hi Russ, Here are just some pragmatic considerations. Personally I am against data hiding, but I obviously won't convince you in that regard. There are some pros and cons as with anything, and I feel the cons outweight the pros (namely that users of code should be able to use how they want, even if it means shooting themselves in the foot; and the fact that priv somewhat breaks the dynamics of python) Even if your proposal were to go through, you are looking at probably 2 years before it can even be used. Python3 is basically in freeze mode, and it contains the biggest change in python syntax for a long time. I know it doesn't seem like a big change to you to add a priv keyword, but python very rarely adds keywords, so it's a long shot merely for that reason. This is something that potentially would be under consideration for something like 3.2 or higher I think, so if you want to get the job done now, this topic or trying to convince other long time python users isn't going to accomplish your goals. Leading underscore takes two keystrokes to type (shift, _) while priv, private, etc takes many more. If you are too lazy to type "_var" then how come you aren't too lazy to type "priv var"? Too me it seems like more typing. If the primary objection to leading underscores is looks, it seems like you unnecesarily avoid them for a pointless reason. There are ugly aspects to every language, and there isn't really a better convention to use that I can see. Without of course implementing keywords, which are conceptually difficult to think about in terms of python object model - although you might be able to come up with a way. But if you have a better naming convention or strategy that you want to try on your code, nothing is stopping you. You can use one of the hacks found in this thread, or come up with your own hack, to more or less accomplish what you want. It should take 30 minutes or less to set up, and you are done with it. The internals of python make it difficult to do more than that, but you are welcome to create your own python fork if you think you are up to it. Although I think that would be more than 30 minutes of work. And feel free to try other languages. No one claimed python is the best for every circumstance. Well, if someone claimed that they are just fooling themselves. Python is a good hacker language that scales pretty well into enterprise and web services; and can be used for other things as well. I don't believe that data prevention (we aren't really talking about just hiding here) is necessary for 99% of tasks, but other people think differently, so there are plenty of languages that implement these features. Good luck finding a solution to fit your project. However I don't think trying to get a "priv" keyword into official python is feasable unless you want to wait a very long time and go hoarse from shouting :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
"Well, "common" in Prolog, Smalltalk, Haskell, ML, and Erlang is hardly common in general. I'll bet that Java and C/C++ are used more in North Dakota than all those languages combined are used in the entire world." I would say python has more in common with the mentioned family than with the C or java families, although I guess it's more in between. Perl, PHP and Ruby all have significant variable names also. It is not that uncommon. 2) Local data within functions is hidden. Should you have access to that too? Are you insulted that you don't? Local data within functions is not hidden. Local data within functions vanish when the function completes. The ability for temporary data is important, and the convention of having functions be temporary keeps things sane. Not quite the same as what this discussion is about. All of the attributes of an object also vanish when the object does... 3) I have suggested that "indirect" or "back door" access could be provided to private data and methods via some sort of name mangling rule akin to the current rule for leading double underscores. This would provide access in a pinch, but it would make sure the client is aware that he or she or it is accessing private data (and it would do so without leading underscores). I honestly don't get the strong objection to leading underscores. They are a low-tech way of saying "don't touch", which won't muck about with very sticky implementation problems that private attributes would have, potential performance problems etc. They work NOW. Even if priv or some such is in the running to be added to python, it's going to be years. 4) My understanding is that most Python software is released or shipped as source code (or at least with the source code included). That means that the client would need only to remove my suggested "priv" keyword to gain access. Have you ever actually had to use Python software for which you had no access to the source code? So when someone releases an api doesn't match what I am doing 100%, I should fork the project? This doesn't seem to be a good solution for anybody. And it seems exceptionally dumb to do so just to go through and remove some keywords. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Can we plez not try and ruin my fave language with a useless concept? Strict data hiding is only necessary because textbooks say it is. Use method attributes or some other hack if you really must (people won't know it's there unless they look, and if they are looking, maybe they have a reason?) I heard a few emails back the argument that "you don't know how code might be used", in favor of data hiding. Um. Excuse me? You don't know how code might be used to me is a good reason not to overly protect anything. This lets people use code in different ways than you might think. Seriously, use java or some other such thing. It's not like there aren't plenty of other languages to choose from. We aren't against data hiding because we have python-colored glasses and are trying to stick up for our favorite language after all. For some of us, myself included, the lack of data hiding is one of the plusses of the language. I have done enough development with big locked down systems to know how frustrating it is when someone tells me how I am supposed to use them. If data hiding were to exist in python, someone would make a big system and use it excessively, and it would eventually get very irritating. Just like it is when working with big c++ or java systems. Please, just drop this topic. It's ridiculous. If you have customers who use your code in bad ways, and then complain when you change something they relied on you, I feel for you, but have you thought that maybe the way they are trying to use it makes more sense than the way you are trying to force them to? Ok, most likely your way is better. So hide the data a little better, but there is still no reason to ENFORCE it. Sorry for the rant, I don't usually rant, but this is a sore subject for me and one that keeps me using python. If the framework says I must do object.move(-5), but the move function does collision detection, then I want to be able to say object.x-=5 if I decide I don't need the collision detection. Maybe later the designer will decide that it is object.pos instead of object.x, object.y, which will break my code. My own damn fault. And if I don't feel like fixing it, I will subclass object, and make x a property that returns and sets pos[0]. Or maybe the designer was nice enough to do that for me himself. I'm serious, if data hiding were added, I would be looking around for another language. I wouldn't stop using python if no one used these features, but I would start looking for sure. -- http://mail.python.org/mailman/listinfo/python-list
Re: php vs python
Yeah I would agree that a decent (a few steps below good in my book) programmer should be able to have a decent handle on a new language, given some acclimatization time of course. The amount of time this period lasts varies on the language said programmer is learning, as well as the languages he knows. If they are far different (say going from object oriented to functional) it will take longer to learn. But it's not to say that after learning it, his code will be bad. Maybe not as good as experts, but not bad. But I would say the jump from "not bad" code to "good" code; or the jump from "good" code to "great" code are huge leaps. And in a badly designed language, it could be argued that even the best code is lacking. To say that language doesn't matter at all is extremely silly, otherwise we wouldn't have 5 million languages. Most languages are created, not just for the fun of it, but to solve something lacking in what is available elsewhere. (OK, there are a lot of languages people have created just because they are geeks, but most languages that people actually use are purposeful). Python was created to have something easier than perl and more powerful than bash to write shell scripts with and automate system administration tasks. PHP was created to enhance html with a powerful integrated server language that was easier than c but not alien to it. It was a replacement for cgi. For me, php is far too flat, making it pretty tough to navigate and get a handle on. If you know what you want to do, it probably has something to fit that task, but for exploring it's not fun. I rather enjoy python, where I can play around at the interpreter and try new things. PHP also is not very strict when it comes to types, even less strict than python, and in my newbieness that has caused me loads of problems. But I know people who swear by PHP, and I admit it has been used for many great sites, so it can't be that bad. Still, outside of the web sphere, it is a bit odd to use PHP. Not necesarily bad, just a bit odd. And there are situations that are a bit odd for python also (sound editing,etc). -- http://mail.python.org/mailman/listinfo/python-list
Re: Struct usages in Python
I don't know if this will go through (my posts seem to have become blocked lately), but I'll give it a shot anyhow. You seem to be under a misconception that a python list is similar to a list in say, Java or other languages that have a rigid idea of variables and types. In python, a list is a list of objects - any type of object can be stored in a list. Just as you don't declare types for variables, you also don't declare types for lists. Here is your modified code: class Event(): def __init__(self, cameraEventType="", zone=99, setDay="",setTime ="", clrTime=""): self.cameraEventType = cameraEventType self.zone = zone self.setDay = setDay self.setTime = setTime self.clrTime = clrTime class EventTimeFilter: def __init__(self): self.event = [] #Create an empty list, bind to the name "event" under the "self" namespace self.event.append(Event()) #Create an event object and append to the end of the list Python won't stop you from putting other objects into self.event besides Event objects, but in practice this isn't often an issue. The real benefit, is if you subclass event or make some other type of object that is similar to events, with maybe some of the same fields, you can still store them in the list and it will play along with the rest of your code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Here is a quick, ugly way you can easily hide data, although persistent
clients can still bypass it. x.__dict__ is ugly, though not any uglier than
x.__Ugly__Internal__Variable__Do__Not__Set
Another option would be to use another structure, such as a dictionary or
list, and store variables in there proxying to it from get/set functions (or
__getattr__ __setattr__). Or just don't document this.
class HideTest(object):
def __init__(self):
self.__dict__["beans"] = 5
def __setattr__(self,key,val):
if key == "beans":
raise Exception("Cannot set this attribute")
return super(HideTest,self).__setattr__(key,val)
b = HideTest()
print "b.beans is",b.beans
try:
b.beans = 5
except:
print "Cannot set"
Also the point of underscore rules have never been to keep clients from
accessing variables. Read about them in PEP8:
http://www.python.org/dev/peps/pep-0008/
They are primarily to handle specific name conflict situations, and
secondarily to inform users when they might be mucking about with something
at a lower level. Using a keyword could work I suppose for the module-level
convention, as well as for the name mangling. Implementation wise it seems
a bit tricky to use keywords for this. For the purposes of informing users
however, keywords versus underscore is a terrible idea. dir() as is makes
it clear, with underscores, which variables are safe to use and which are
potentially dangerous. Rewriting dir() to print extra information about
names seems incredibly problematic as well. I really like the idea of
having variables that may be unsafe to use but I can still use them if I
want to, and the underscore rules are the most clean way I can see for this
purpose (not to mention all of the history). I agree that they do look ugly
of course. I also tend not to use them in my code as well.
This has been brought up so many times before, and turned down again and
again. Working around it as best you can is your best bet, especially since
a major change like this could never happen until well after python 3.0.
(Who knows how long it will take before 3.0 is fully adopted enough to move
on from that)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
There are certainly situations where data hiding is useful and perhaps a wanted feature, but there has to be at least one place where I can use what I want when I want to with some high and mighty designer telling me what I should and shouldn't access. One of the reasons they have data hiding in something like Java, is because often you will use get/set functions that actually do more than tell you the value of an attribute. Python uses properties or overloaded functions for this same mechanism. Because of this design, you are less likely to have to change an "internal" attribute that is relied on in user code. Instead of telling the user that now they have to use a different function to get a value, or changing the name of an attribute and confusing users, you can always proxy things making the interface stay backwards compatible. Obviously this doesn't suit all situations, every language consideration is going to be good in some cases and bad in others. Otherwise it wouldn't be a choice. Python has made an actual choice to NOT include this feature. Things like properties or underscore conventions etc are alternative solutions for things that data hiding is supposed to solve. Obviously it is open source, so if enough people complain loud enough it could change, but this is something that has stuck for a long time, and also a reason many long time python developers are still using it. Just as open source software allows users to do new things with old programmers or revive projects which are dead; python allows libraries to be extended easily protecting users from designers who think they know what we want to be able to do with their code. But yeah, in a situation where you want the freedom to change around internal apis, and your customers won't follow your guidelines, I feel for you :) I think mostly we all fear that if true data hiding were added (a la java), that it would be abused and not limited to situations you describe. Which is not necesarily a valid assumption, since python has been around a long time with the philosophy it has (it IS a philosophy and guides many other python features or lack of features), and library writers may continue to develop the way they have previously. All of us who complain when anyone mentions data hiding would not use these features, and I'm fairly sure the system libraries would remain open. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python web development that resembles PHP or classic ASP
Hi Erik, As far as I know the only full web framework that works with a primarily inline style is spyce, which is not currently under active development. I used it for a while and it was the first python framework I used. I think it's pretty good, if a little bit of an underdog. That said, using a controller based framework it would be pretty easy to emulate what you are wanting. Find a templating language that fits what you want, build the controller to map to the directories, and pass into templates all the objects that are needed to interact (response/request objects etc) and you're set. -- http://mail.python.org/mailman/listinfo/python-list
Re: Code correctness, and testing strategies
I can see both sides of this argument, and I think TDD is great in some cases and not so great in others. I have used it before, but don't use it often, as the programs I write are very difficult to automatically test. (Games, which many of the bugs have to do with whether an optimization produces a visual artifact or not etc. Not possible to test that!) As far as time spent testing, it obviously various per project, person, and methodology. But I think you have some misconceptions about coding time. With TDD, you cannot measure test writing and code separately. Here's why. When you write code and then write a test for it, you spend a lot of time thinking about how the code is going to look while you are writing the code. You plan what the code is going to look like, what arguments are going to be passed to a function, how the code might be used by other code, etc. This is thinking time, with no code written. This is also interleaved with the actual time spent writing the code. (You are thinking of the plan while you are typing the actual code). Then you will likely do some sort of debugging at least, if not writing a test. This doesn't take much thought as you have already front loaded the thought. "Well I should print here to make sure this line is correct." >From a TDD perspective, most of the actual time is fairly the same, just shifted around. The thought process that I mentioned, of how code is going to be used or how it fits the system, instead of being hinged on the code, is now hinged on writing the test. This makes the thought process more formal than in the other methodology. Instead of thinking of one thing (how a function may be used) while doing something else (writing an if statement within some logic), you are actually writing code based on the system instead of the internal logic. Then, you write some code that makes it work. In many cases, (and in my experience) the actual code is easier to write in TDD, because it is more focused and directed. I am not writing one thing and keeping in mind other things. You think, plan, and then write to spec. It is most certainly a more formal process, and can be hard to get used to. And it doesn't work in all situations of course. But timewise it seems like all the processes are the same. Without tdd, you might, instead of writing a test per say, still spend that time writing a doc string, or just looking at where a function will be used to see what the code should look like etc. I think though that test-first streamlines things a bit. By itself I don't think it makes the process faster, and that front work of writing the tests can definitely feel slower. Further on is where you have the most benefit of having tests. And with practice you can get faster at it too. Most programmers have their own methodology that they have used for a while, so they are fast at it. Any change in that is going to be extremely sluggish until you are used to it. You should try TDD at least once for a small or medium project and go all the way through with it just to get a feel for it. If you can afford to of course :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is slow
Judging python's speed by how fast websites go is not going to work very well. There are many things that can bog down the "speed" of loading a web site, especially if you are judging speed by how long a page takes to load. torontolife.com is loading extremely slow for me also. So is wikipedia. Much slower than say, code.google.com, or the trac site I have running on my remote server. I have seen just as many slow php sites as slow python sites. Also, the hosting solution plays a huge part in how fast a site responds. If someone is using python through cgi, that IS going to be very slow, whereas other solutions are faster. PHP sites are not hosted on cgi, while many python solutions sadly still are. So yeah, finding specific sites that are slow and written in python and claiming that it's slow is trolling. Youtube is slow these days, but a year or more ago it was very fast. They just haven't been able to keep up with demand. (Even movies play slow, constantly buffering, and the movies don't even play from python). Of all domains, the web domain needs speed (from logic code, where python resides) the LEAST, because so much of the time is spent buffering packets, alternating between threads or processes, or accessing the database or files. All of these operations contribute the most to slow web pages. And before you complain that python has to "buffer packets", or "access the database", all of these operations are done at the C level (or lower). Python is slow, but php is slower. And python's speed is always improving. On the other hand, it is much easier to find good php hosting services, due to it's wide availability - better hosting = faster sites. -- http://mail.python.org/mailman/listinfo/python-list
Re: MVC
In my experience, python is very pattern agnostic. You can do functional or object oriented or procedural fairly easily, have deep or light object trees, or even mix procedural style with some object oriented code if you like. "There should be one way to do it" tends to not apply as much as some would say, although the language doesn't bend over backward to make sure programmers have flexibility. MVC is a well respected pattern, and most of the major python web frameworks are designed in an MVC way, so you should be just fine to use MVC for your application. Worry more about what pattern fits your application, than whether your pattern fits the language. For myself, whenever I try to do strict MVC, it always tends to blend together. I usually get some sort of MC+V or MV+C sort of hybrid. The model is also the view, or the controller is also the model. But that's just how I think. Just keep in mind that python is not java, and you should be able to transition very easily. In fact, you could pretend python is java and go far, but you risk irritating other python programmers who look at your code :) We had to use jython for a class, and my friend's code (he's a java programmer) made me want to pull out my hair. Private variables and get/set functions all over the place... -- http://mail.python.org/mailman/listinfo/python-list
Re: Passing functions around and executing
Here's a quick dumb example, hope it helps:
def function1(a,b,c):
print a,b,c
def function2(x):
print x
def function3(y):
print y+3
def executeall(list):
print "setting up"
for function,args in list:
function(*args) #Calls the function passing in the arguments
mylist = [[function1,(1,2,3)],[function2,("green",)],[function3,(5.5,)]]
executeall(mylist)
-
The hard part is the fact that you mentioned some arguments need to be
passed in, some of the time. This kind of situation makes the most sense if
all of the functions take the same arguments (or no arguments). Then you
could just do this:
def function1():
print 1
def function2():
print 2
def function3():
print 3
def executeall(list):
print "setting up"
for function in list:
function()
mylist = [function1,function2,function3]
executeall(mylist)
--
So you see, treating functions as regular objects and passing them around,
is as easy as not putting the call operator (parenthesis) to the right of
the function name.
print function #Prints the representation of the function object
print function() #Calls the function and then prints what the function
returns
Hope it helps.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Free Memory
Yeah I don't know much about locals or globals. I've never used them
before, just know they are there. But anyway, to illustrate what I meant by
the interesting behavior, here is the output (and sorry for it being so
long):
IDLE 2.6a2
>>> globals()
{'__builtins__': , '__name__': '__main__',
'__doc__': None, '__package__': None}
>>> globals().clear()
>>> globals()
{'__builtins__': {'bytearray': , 'IndexError': , 'all': , 'help': Type
help() for interactive help, or help(object) for help about object., 'vars':
, 'SyntaxError': ,
'unicode': , 'UnicodeDecodeError': , 'isinstance': , 'copyright': Copyright (c) 2001-2008 Python Software
Foundation.
All Rights Reserved.
Copyright (c) 2000 BeOpen.com.
All Rights Reserved.
Copyright (c) 1995-2001 Corporation for National Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved., 'NameError': ,
'BytesWarning': , 'dict': ,
'input': , 'oct': , 'bin':
, 'SystemExit': ,
'StandardError': , 'format': , 'repr': , 'sorted': , 'False': False, 'RuntimeWarning': , 'list': , 'iter': , 'reload': , 'Warning': , '__package__': None, 'round': , 'dir': , 'cmp': ,
'set': , 'bytes': , 'reduce': , 'intern': , 'issubclass': , 'Ellipsis': Ellipsis, 'EOFError': , 'locals': , 'slice': , 'FloatingPointError': ,
'sum': , 'getattr': ,
'abs': , 'exit': Use exit() or Ctrl-Z plus Return to
exit, 'print': , 'True': True, 'FutureWarning':
, 'ImportWarning': , 'None': None, 'hash': ,
'len': , 'credits': Thanks to CWI, CNRI,
BeOpen.com, Zope Corporation and a cast of thousands
for supporting Python development. See www.python.org for more
information., 'frozenset': , '__name__': '__builtin__',
'ord': , 'super': , '_': None,
'TypeError': , 'license': Type license() to see
the full license text, 'KeyboardInterrupt': , 'UserWarning': , 'filter': , 'range':
, 'staticmethod': ,
'SystemError': , 'BaseException': , 'pow': , 'RuntimeError':
, 'float': , 'MemoryError':
, 'StopIteration': , 'globals': ,
'divmod': , 'enumerate': ,
'apply': , 'LookupError': , 'open': , 'quit': Use
quit() or Ctrl-Z plus Return to exit, 'basestring': ,
'UnicodeError': , 'zip': , 'hex': , 'long': ,
'ReferenceError': , 'ImportError': , 'chr': , 'xrange': , 'type': , '__doc__': "Built-in functions,
exceptions, and other objects.\n\nNoteworthy: None is the `nil' object;
Ellipsis represents `...' in slices.", 'Exception': , 'tuple': , 'UnicodeTranslateError':
, 'reversed': ,
'UnicodeEncodeError': , 'IOError':
, 'hasattr': ,
'delattr': , 'setattr': , 'raw_input': , 'SyntaxWarning': , 'compile': ,
'ArithmeticError': , 'str': ,
'property': , 'GeneratorExit': , 'int': , '__import__': , 'KeyError': , 'coerce':
, 'PendingDeprecationWarning': , 'file': ,
'EnvironmentError': , 'unichr':
, 'id': , 'OSError': , 'DeprecationWarning': , 'min': ,
'UnicodeWarning': , 'execfile': , 'any': , 'complex': , 'bool': , 'ValueError': , 'NotImplemented': NotImplemented, 'map': , 'buffer': , 'max': ,
'object': , 'TabError': ,
'callable': , 'ZeroDivisionError': , 'eval': ,
'__debug__': True, 'IndentationError': ,
'AssertionError': , 'classmethod': , 'UnboundLocalError': ,
'NotImplementedError': ,
'AttributeError': , 'OverflowError': , 'WindowsError': }}
>>>
The OP wanted to clear the interpreter and I took a very broad (and highly
unresearched) stab at it, and saw some behavior that I wasn't expecting.
So before, all the builtin variables are hidden away in __builtins__, but
after clearing globals, they are filled into globals. This doesn't really
make sense to me, but I don't know much about __builtins__ or globals.
I just realized this only happens in idle however. From the python console,
clearing globals REALLY clears globals - even globals() is unbound when you
do that. So it's not such a good thing to do :)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Now what!?
On Sat, May 10, 2008 at 3:57 PM, Grant Edwards <[EMAIL PROTECTED]> wrote: > On a Linux system (and I presume on other Unixes), the kernel > itself (if built with the proper options) knows know how start > a "script" file that starts with the characters "#!". When the > kernel is told to execute a file whose first two bytes are "#!" > (0x32,0x21), it knows to read the newline terminated path of an > executable starting at the byte following the "!" (the third > byte in the file). The kernel then executes that file, > appending the name of the original "script" file to the argv > list. Wow, thanks for the history lesson. I was under the impression that this was a bash thing, I had no idea it went as deep as the kernel! -- http://mail.python.org/mailman/listinfo/python-list
Re: Free Memory
I had some very interesting results with this code to do what is asked: for key in globals().keys(): del globals()[key] for key in locals().keys(): del locals()[key] It might be better to reverse the two steps, I didn't give it much thought. Anyway, when this is done, all of the builtins spill into globals and locals (since __builtin__ was deleted). I thought that was interesting. It did have the effect that is asked for, although there may be more unintended consequences. Also if any objects are attached to any of the builtins I expect they will still be around. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are rank noobs tolerated, here?
There is also the python tutor list: http://mail.python.org/mailman/listinfo/tutor Which is more geared toward beginners. Although I am subscribed to both lists, and they are both matched by the same filter for me so I wont know the difference... But there may be people who are not subscribed to both lists and don't care to listen to beginner discussions. I wouldn't know. There is python irc as well: #python on irc.freenode.net. If you just have a quick question you may be better off trying there first. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame.key.get_pressed[K_a], K_a is not defined!?
The K_a is a constant integer, but you don't need to worry about it's value. It tells you the index in get_pressed() to check for. So: print pygame.key.get_pressed()[pygame.K_a] Says, look at the 97th index in the get_pressed() list and see if that is a 1 or a 0. Or if you use the pygame events: for evt in pygame.event.get(): if evt.type == pygame.KEYDOWN and evt.key == pygame.K_a: print "a pressed" evt.type and evt.key will both be integers that map to one of the type constants and one of the key constants respectively. This way the key constant works in both types of input handling (which are both useful for different types of input). -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to store config or preferences in a multi-platform way.
YAML is a joke if you expect a windows user to be able to hand edit the data. Windows users typically expect a .ini file in the application's directory. (Usually not the users home directory, even if that may be a better location). XML is ok, but .ini is much preferred. If you have a configuration gui or whatever and the file doesn't need to be hand edited, it doesn't really matter what format you store it in. Sqlite db would be fine in this case. Still keep the file as a ".yourappname" file in users home linux directory, and probably do as mentioned above and keep it in their windows home directory. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.5 adoption
On Mon, Apr 21, 2008 at 1:49 PM, Jorgen Grahn <[EMAIL PROTECTED]> wrote: > OP: keep in mind that your users do not see any gain from you using > 2.5. All they see is something that makes your software harder to > install. At some point you can dismiss them as living in the Stone Age, > but the Stone Age is currently 2.1 or something. Maybe 2.2 is, too. Except for the memory bug which 2.5 fixed (not giving memory back), which in some cases with 2.4 could be a really large issue. But in that case you get the benefit whether it was "coded for" 2.5 or not. So it is still safest to develop for a lower common denominator. For me, the best things about 2.5 were the memory fixes/performance, and the inclusion of ctypes in the standard library. The language upgrades are mostly corner cases. If I were the OP, and those corner situations aren't too big of an issue, I would restrict my usage to 2.4 or even 2.3 to allow easier adoption of the software. -- http://mail.python.org/mailman/listinfo/python-list
Re: python setup.py install on Vista?
On Fri, Apr 18, 2008 at 4:29 PM, globalrev <[EMAIL PROTECTED]> wrote: > type "python setup.py install" > > that is used in most "addons" for python. > > well using windows vista, where the h*** am i supposed to type this? > > if it is not doable in windows, what do i have to do instead? just > clicking the setup.py-file never works. > -- > http://mail.python.org/mailman/listinfo/python-list > There are many problems with this on Vista. First, you need a command prompt. You can go to "start menu->all programs->accessories->command prompt" for this. But to install things in vista, you will likely need to be an administrator, and windows won't automatically ask for permission when typing "python setup.py install." So instead of clicking on command prompt, right click it, and choose "run as administrator". A faster way is to type "cmd" in the start menu search area, and wait for "cmd.exe" to come up. Run that as administrator. Once you have a command prompt, you can "cd" into the directory where you want to install the extension. Then, "c:\python25\python setup.py install" should work. If you are using 2.4 or 3.0, it would be "c:\python24\python" or "c:\python30\python" etc. If you installed python somewhere other than the default folder, then you will need to enter that path. To make this process easier, when I want to install an extension, I usually create a .bat file in the extension folder. Right click in the folder and choose new->text file. Rename the file to "install.bat". Right click the file and go to edit. Enter "c:\python25\python setup.py install" into the file and save. Then right click and choose run as administrator, and it should install. You might add a "pause" line in the bat file as well, so that if it has a problem installing, it will stay open so you can see the output. Your best solution is to uninstall vista and use linux :) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Twisted-web] [ANN] Twisted 8.0
It's dangerously close to april fools for this kind of posting! Congrats on the release, it looks mighty impressive. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does python hate cathy?
It seems like this is mostly a non-issue. The original code actually works correctly (of course the updated versions that solve the exception problem are probably better). The only thing that is going haywire is the interpreter shutdown process. I think it is going a bit overboard to "consider __del__ harmful" because it might throw an exception as the program is quitting. It is important to not rely on __del__ too much but there can be some designs where you need to know when something is gone, and you don't know exactly where or when something is deleted. Then again, I can count the number of times I have ever needed __del__ with no fingers (never used it!). Still, quite interesting to explore. -- http://mail.python.org/mailman/listinfo/python-list
Python to C/C++
(sorry michael, didn't mean to personal post On Wed, Mar 19, 2008 at 9:24 AM, Michael Wieher wrote: > I think py2exe does this, but it might be a bit bloated No, py2exe basically bundles the main script and the interpreter together so it's easy to run and requires no python installation. Look into pyrex and pypy. A mature translator doesn't exist. Also there is ctypes which goes in reverse letting you use more c from python easily. -- http://mail.python.org/mailman/listinfo/python-list
Re: a Roguelike in Python
On Wed, Mar 12, 2008 at 9:23 AM, Carl Banks <[EMAIL PROTECTED]> wrote: > Even though it's typically used for graphical games, PyGame would be a > good way to make a cross-platform "text-mode" game. It should be > pretty straightforward to simulate a text mode terminal using a grid > of sprites. (There might even be some third-party text terminals out > there.) This is a cool technique, and also gives the game designer a lot of freedom in their representation. It can continue to look old school while also letting you have icons where they may be appropriate, or add an eye on your gridbug 'x' just for fun :) This technique was used in phoenix from one of the pyweek competitions: http://www.pyweek.org/e/Cursed/ By the way, that game emulates curses as well. If you go with pygame display only, you are losing some compatibility as well, as it won't run on textmode only systems. No roguelikes over ssh :( -- http://mail.python.org/mailman/listinfo/python-list
Re: Removing objects
On Jan 22, 2008 10:59 PM, <[EMAIL PROTECTED]> wrote: > I am writing a game, and it must keep a list of objects. I've been > representing this as a list, but I need an object to be able to remove > itself. It doesn't know it's own index. If I tried to make each object > keep track of it's own index, it would be invalidated when any object > with a lower index was deleted. The error was that when I called > list.remove(self), it just removed the first thing in hte list with > the same type as what I wanted, rather than the object I wanted. The > objects have no identifying charachteristics, other than thier > location in memory > > So my question: How do I look something up in a list by it's location > in memory? does python even support pointers? > > Is there a better way? To put it simply, list.remove(self) ought to work. Are you sure it's not working? list.remove self doesn't delete the first matching type, it deletes the first object that IS what you passed, or failing that, it deletes the first object that == what you pass. I use an idiom often in my games, where rather than deleting objects on the fly, which is not very thread-safe in case you have something scanning through the objects, I set a property .kill on objects that are about to die, and then rebuild the list in the main loop with only objects that haven't been killed. I don't know if it's better, but it would probably work in your situation if list.remove(self) isn't working (which is strange). The other benefit of my idiom, is that objects don't need to have a reference to the object list, and any other function that wants to delete that object needs no other references besides the object itself. I have trouble with references a lot in complex games, and where I can I prefer not to have them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
On Dec 17, 2007 1:10 PM, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Hem... May I remind you that Python doesn't have block comments ?-) I suppose we could argue semantics, since """ strings are actually processed, but they are basically block comments. So, there we are, multiline strings AND block comments! > > However, inspection of a vast corpus of code might lead one > > to believe that any commenting capability was completely unnecessary. Lol! Who uses them dern comments anyway? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is a "real" C-Python possible?
> > > > Kay Schluehr wrote:
> > > > Python 2.6 and 3.0 have a more Pythonic way for the problem:
> > > > class A(object):
> > > > @property
> > > > def foo(self):
> > > > return self._foo
> > > > @foo.setter
> > > > def foo(self, value)
> > > > self._foo = value
> > > > @foo.deletter
> > > > def foo(self)
> > > > del self._foo
> > > > class B(A):
> > > > # one can even overwrite the getter in a subclass
> > > > @foo.getter
> > > > def foo(self):
> > > > return self._foo * 2
> > > > Christian
On Dec 12, 2007 12:57 PM, George Sakkis <[EMAIL PROTECTED]> wrote:
> 1. The property name ('foo') is repeated *5* times for a single class.
> Talk about DRY.
> 2. Total inconsistency: @property for the getter when it is defined
> for the first time, @foo.setter/@foo.deletter for the setter/deletter,
> @foo.getter when the getter is redefined. WTF ?!
Eww, I agree with George here, with respect to these two points. When
I looked at this my first wtf was the @property and then @foo.getter
business. I really don't mind the current way of doing things: attr =
property(get,set). Other mechanisms can be created with getattr
routines. I don't really like this new syntax at all. Too many @
marks, inconsistancies, and too many foos everywhere. Not to mention
how long it reads. For only getters, it's not bad though, and a
little better than property().
Decorators really don't feel pythonic to me at all, mostly due to the
@ symbol, but it looks really awful in this instance.
What about this, somewhat similar but not ugly syntax:
class A:
foo = property()
def foo.get():
return self._foo
def foo.delete():
del self._foo
def foo.set(val):
self._foo = val
Defining something with a dot is currently a syntax error. Ok, so
it's still too many foos. At least it's consistent. I'm not really
proposing this btw. I'd rather not introduce more specialized syntax.
How about abusing with:
class A:
with property("foo"):
def get
def set...
There's your thunk, and I really like with, but am saddened that it
has such limited use at the moment. Of course this isn't really what
with is for...
Can anyone tell me what's wrong about the current property() syntax,
besides namespace polution?
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Python" is not a good name, should rename to "Athon"
Monty Python pioneered (or at least pioneered the organized televising of) a form of humor where there is no punchline or reason something is funny, it just is (or isn't). I find about half of it very funny, and the rest very unfunny. I used to find it more hilarious than I do now. It's an extremely subjective humor. It's not that the jokes aren't funny (or meant to be) it's that there is nothing to "get". If you are trying to understand it (get the joke), it's a lost cause :) When they do have a joke which has a "reason" it loses its impact if the rest of the silliness didn't affect you. This form of humor continues in shows like Saturday Night Live. They do have actual jokes on that show for instance, but many of the skits are just silly characters doing silly things that often don't make sense, and actual punchlines at the end of a skit are fairly rare. On Dec 6, 2007 10:14 PM, James Stroud <[EMAIL PROTECTED]> wrote: > Terry Reedy wrote: > > "Tóth Csaba" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > | > > | >> Python name is not funny for me. Even the Monty Python, because its > > hard > > | >> to translate their jokes, and in my country they are not so popular. > > The jokes translate just fine in my country, but dare I admit that > python (or Monty Python, rather) is not funny for me either. I think > I've actually heard someone say "that the jokes aren't funny is part of > the humor". I guess some of us will never get it. Now Benny Hill--that's > another story! > > > -- > James Stroud > UCLA-DOE Institute for Genomics and Proteomics > Box 951570 > Los Angeles, CA 90095 > > http://www.jamesstroud.com > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On 24 Nov 2007 13:56:37 GMT, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> So::
>
> def meth(self):
> using self:
> tmp = raw_input('Enter age: ')
> age = int(tmp)
>
> becomes::
>
> def meth(self):
> using self:
> self.tmp = self.raw_input('Enter age: ')
> self.age = self.int(tmp)
>
> Binding `tmp` unnecessarily to the object and trying to get `raw_input()`
> and `int()` from the object. Ouch. :-)
Yes, that's no good. So you would write it like so:
def meth(self,*args):
tmp = int(raw_input('Enter age:'))
using self:
age = tmp
Still an unnecessary lookup on tmp though :) And it would be useless
to use it for one assignment, the idea is to eliminate all the typing
with this:
self.var1 = 5
self.var2 = "a value"
self.var3 = stuff
self.var4 = [2,54,7,7]
self.var5 = "dingaling"
self.var6 = 6.4
self.var7 = 1
self.var8 = False
self.var9 = True
Of course that "self.var3 = stuff" under the using would result in a
bad lookup for "stuff", but the programmer who wanted to use this
would have to realize this and try to avoid it.
I have been known from time to time, for long assignments such as
this, to turn a string with keys and values into a dictionary, and
then update __dict__ with that dictionary, hehe. "var1,5;var2,"a
value";var3,stuff" Not the best practice but the fastest to type.
Sometimes I actually use a dictionary, but typing all of the quotes
for the keys gets old.
If there were a "using" or if the with statement would handle
something like this, I wouldn't use it. "s." is only 2 characters. I
saw chained dots mentioned. Chained dots are 2 characters. Why are
we still discussing this? "s." is the answer, or pulling the
attributes into local vars if you are going to use them many times, to
save lookup. This is not a band-aid, this is an actual valid
programming technique. There is more to programming than typing...
Self is never going away, most python programmers generally like or
aren't bothered by it, if you are new to the language try to get used
to it, if it's too bothersome you can use one of the hacks or try
other languages. I don't mean to be snobby either, one language does
not fit all.
--
http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
Ton Van Vliet: > [... using/with ...] This looks like a really nice little construct, and solves my small quirk issue (which has popped up maybe twice in my python experience). It could also be a solution to the OP's problem. The issue of course is disambiguation. Is EVERY name looked up in the tagged object, or only assignments? Does it copy attributes over and make everything local and then copy it back at the end (like you would kind of expect in a function)? Or is everything routed to the parent. It gets very sticky very fast, but since it's in a block, the issues aren't as evil as when they show up if you try to get rid of self altogether. It also solves more than just the self issue, allowing you to more quickly assign multiple attributes of an object as well. In your example: def somefunction(self, ...): using self: a = ... b = ... ... c = a + b The biggest issue is, what if you need to do more: def somefunction(self, ...): using self: a = ... b = ... c = a + int(b) What is int? Is it self.int? I suppose the simplest solution is to: always assign as an attribute, and lookup as an attribute first going to normal lookup rules after that. As far as using [xxx], I don't think the interpreter needs to deal with [xxx] until it actually executes the line. [xxx] would just be a normal python expression, the result of which is used for the attribute lookup and assignments within the block. This would somewhat solve the toy vector example: def abs(self): using self: return math.sqrt(x*x + y*y + z*z) Unfortunately the performance would be slightly worse do to the extra lookup rules (self.math? no, self.__getattr__(math)? no, self.parentclass.__getattr__(math)? no, etc) The OP will probably say, "why not build the [using self] block into a method definition": def abs(): return math.sqrt(x*x . But this would cause problems and slowdown for pretty much all python code in existence, and reopens the whole discussion of why removing self is bad :) Anyway, I'm for the "using" construct, as unlikely as it is. It's not necessary, but something similar could help alleviate a bit of the tedium that is perceived by some python users, without affecting anyone else. Of course, this is all theory, and it's unknown (by me) if the python compiler can even handle such a thing. Even if it could, it's probably not an easy task. -- http://mail.python.org/mailman/listinfo/python-list
Re: Catching a segfault in a Python library
On 24 Nov 2007 08:41:24 GMT, Ayaz Ahmed Khan <[EMAIL PROTECTED]> wrote: > Donn Ingle wrote: > > Already done, the code within PIL is causing the crash. It gets ugly and > > out of my remit. It's a freetype/Pil thing and I simply want to a way to > > catch it when it happens. > > Since a segfault ends the process, I am asking about "wrappers" around > > code > > to catch a segfault. > > > > \d > > Wouldn't it be better to narrow down to what in your code is invoking PIL > in a manner in which PIL exhibits such behaviour, and handle it within > your code? > > Just a thought! > > -- > Ayaz Ahmed Khan > > -- > http://mail.python.org/mailman/listinfo/python-list > I think the idea is, certain fonts in his collection may be corrupt, and he wants to just scan through and load them, ignoring the ones that make the program crash. The bug in this case lies with a third party and isn't something he can easily fix (although he can file reports to the third party (PIL)). This has come up for me as well with loading meshes in a 3d application. The user or someone may include a corrupt file, and it's not nice for the application to just crash when that happens, asking them if they want to debug it. I haven't really found a solution, just have tried to prevent corrupted files in the system for now. Let me know if you get this solved :) -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
Most of the time self doesn't bother me in the slightest. The one time it does bother me however, is when I am turning a function into a method. In this case, often I have many local variables which I actually want to be instance variables, so I have to add self to all of them. Of course, this is going to cause me some grief no matter which language I am using. If it was enough trouble, it wouldn't be hard to make a filter that converts my code automatically. In other cases it's not a big deal. When I program in java I write "this." on everything anyway, as my Java teacher recommended. So for me it's not different than java, the way I write it. I don't particularly like too much use of special characters, such as the @ in ruby. I actually don't like the @ in python for decorators either. So ugly :( I would not like to see a special character or leading dot used for attributes for this reason. Human readable text is nice, because even if you haven't programmed in the language for a while, you don't have to remember as many special symbols. I think using s. is your best bet, but for me, s is then just another special character that needs to be memorized, whereas self. is self descriptive. One persons trash is another person's treasure. On Nov 23, 2007 4:56 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > > Python uses "self" (and textual notation when possible) because its > designers consider that symbols reduce readability. Self won't go > away. :-P > > The issue is related to the first and seventh lines in The Zen of > Python, > > 1. "Beautiful is better than ugly" > 7. "Readability counts." > > My opinion is that "self" is a minor issue in python that we can all > live with. > > > On Nov 21, 9:51 pm, braver <[EMAIL PROTECTED]> wrote: > > Is there any trick to get rid of having to type the annoying, > > character-eating "self." prefix everywhere in a class? Sometimes I > > avoid OO just not to deal with its verbosity. In fact, I try to use > > Ruby anywhere speed is not crucial especially for @ prefix is better- > > looking than self. > > > > But things grow -- is there any metaprogramming tricks or whatnot we > > can throw on the self? > > > > Cheers, > > Alexy > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too complex ?!?!?!
On Nov 22, 2007 1:04 PM, Brian <[EMAIL PROTECTED]> wrote: > / Chime Mode > I have, in fact, sent this thread to my friend. > His limiting factors are > > - money-control people favor MS platforms > - C# and VS have minimal cost impact for academia > - sys admins have everything locked down (probably > essential for high school and community college) > - both Python 2.4.2, then 2.5.1, on XP and Win2k > crashed approx 10% of lab cptrs, so lab techs refused > to allow further install of any 'third-party' s/w. > (side note - I have installed Python and all the > supporting stuff for PyVISA on 14 work-site (11 XP, 3 > Debian) cptrs with no problem, so I do not understand). > - no such thing as TAs in JC or HS. > - CS instructors, for the effected schools, are not > allowed to config machines or admin the network. > - money-control people want students to learn skills > that are on the IT buzz-word list. > - my friend is no longer allowed to use me as an > 'unofficial' assistant in these classes (not considered > qualified because I only have a B.S. degree), so he > only uses stuff that existing staff are (supposedly) > familiar with... > / Chime Mode > > I told my friend, the wannabe Python instructor, to > walk away from any more volunteer work, and stick to > the paid stuff. American education, what a mess... > > luck, > Brian > > -- > http://mail.python.org/mailman/listinfo/python-list > Wow... Sounds like in this instance (and probably most such cases), none of the problems are really python related. Just a stupid institution thing. Everyone uses MS because it's what they are used to, and MS pays a lot to keep it this way. The only somewhat valid strike against python is the crashing, which is a real WTF. My guess is that python was not the cause of the crashes, and the admins assumed so since they were prejudiced against it. I had python crash at school pretty much immediately after installing it, but guess what - other people in the same lab have their vista computers crash frequently without installing python. Uh, maybe microsoft and their crappy vista OS is to blame... Oh, and I told the admins about the crashes and they said they have never seen them crash. ... Ok. How come every time I come into lab and turn the computer on it gives me the "your computer had a problem, do you want me to send data to microsoft about it?". Lol. I still think that python does inherently have some issues with regard to teaching it in a classroom setting, but it's mostly minor quibbles. Obviously in America, the main problem is we just can't possibly hope to displace the juggernaut. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too complex ?!?!?!
(Oops, sent as private, reposting to list) On Nov 20, 2007 12:36 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > FWIW it's trivial to run pyflakes on your code (automatically behind > the scenes) to get syntax checking; in vim, my syntax errors get > underlined immediately for python code. It's especially nice for > large web applications, where having to go reload a page only to > discover you typed "if a=1:" or some silliness actually takes some > amount of time. > > I also get function prototypes on the status line (so, e.g., the > elsethread example of confusing list.extend and list.append is > mitigated to a large degree). > > Dynamic typing loses some info, but you can get most of the big > benefits with it. > > -- > http://mail.python.org/mailman/listinfo/python-list > That sounds really cool. What do I have to do to set up vim so it does that for me? Back on topic, I don't think python has lost it's simplicity. It has added many features in the last few versions, but none of them are requirements for learning. There are some things in python that I can see might be sticky points for instructors, but these things have always been an issue. The IDE is one thing. With python being agnostic about so many things, such as the IDE, an instructor has to choose which ide would be best to teach with. And none of the ides available can match Microsoft's offering (One of the best, if not THE best IDE available for any language). As someone who only uses 2% of the features of an IDE if I am ever forced to use one, I don't respect that, but many people swear by it. The interactive interpreter is great as well, but that scenario doesn't work well for everybody. If someone doesn't have much experience with command line tools, than a microsoft word-ish (like VS) interface is going to be more condusive for them. You also have to think about a classroom scenario. I think python works very well for pair programming, one-on-one tutoring, or through text correspondence. In a class, there are many situations for error. Being tab-based is a real problem in this instance, when trying to tell someone how to write something. You have to be clear about where to tab over. With blocks, it is much easier to verbalize. I have run into this when helping people to code in person, but with one-on-one and their full attention it's not so hard to disambiguate things. In a classroom where many people are having different sorts of problems, I can see where issues might crop up. Then the library situation, which is a strength and weakness of python. It is starting to be remedied with easy_install, but easy_install on windows is a joke (and there are still issues with it under linux at times). There are many libraries but on windows it can often be a chore to track down the ones that you want, and while the batteries are included with respect to strong language features and web modules; the batteries are definitely missing in some key areas: gui (tk is really quite awful, hard to learn, and ugly), web application, graphics (pygame, PIL, opengl), sound/music (uh, any standard libs for this? pygame is the only one that comes to mind for me), etc. I'd like to see a few things. Easy install being included with pygame as standard, with a gui. Ability to browse the cheesshop and look for specific things, such as image processing, graphics display, gui, etc. A list of suggested extra libraries to install when you run the python installer: (Tick off the web framework(s) you want to install). A nicer default gui (don't know what that would be, yes I am aware of the huge flame war and wound this would open up). A slightly improved interpreter - when entering a long function and getting it wrong, I want to bring back the whole function, not just line by line. A better standard IDE - too bad the best ones all seem to be commercial. So that is mostly a wish list, and some of those things will never happen, but the standard easy install with a gui would be a good thing to work towards for the windows world. -- http://mail.python.org/mailman/listinfo/python-list
Re: still struggling, howto use a list-element as a name ?
You would use setattr to bind a name that you don't know:
for pin in self.pin:
setattr(self,pin.Name,pin.Value)
However, I'm not sure why you're using a dictionary in this way. I don't
totally understand the context, so I may be wrong, but I would code it more
like this:
class Power_Supply(device):
pins = {'GND':(_DIG_OUT,_par2),'VCC':(_DIG_OUT,_par33)}
def __init__(self):
for pin in pins.items(): #pin will be key,value
setattr(self,pin[0],pin[1])
or even:
class Power_Supply(device):
pins = {'GND':(_DIG_OUT,_par2),'VCC':(_DIG_OUT,_par33)}
def __init__(self):
self.__dict__.update(pins)
#self.__dict__ is the name mapping for any object, update will insert any
new values from a new dictionary into the old one
--
http://mail.python.org/mailman/listinfo/python-list
