Re: Does the Python community really follow the philospy of "Community Matters?"
I think what you have found is a remarkable characteristic of this language. Somehow, perhaps something to do with guido or python itself, python has a very strong non-dogmatic streak. It's a relief really. If I were to pose a "is python or its community really xyz?" I would wonder about the "one best way to do something". One of my first posts here was about three different ways I had built singletons. As a result of that I was given a better way, but no one said any of the other ways were "non-pythonic", it was more, "if you use option one, make sure of this, if you use option two, don't forget that"... As such, python programmers are not there for you to feel superior. If you want a language for a feeling of community, then it hardly matters what language you choose, and if you want a good language, it's secondary if the community gives you that feeling (you should get it from the language itself). And since there IS a python community to go to for help, python has that covered without worrying about it or making it a language feature. It may seems cold, instead of giving warm fuzzies, people will help you with tangible problems, but we are not starting a commune. "Uses a langague with sense of community that advocates for their language over others" is never in a spec. -craig -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading and tkinter
> The statement > > x=x+1 > > (which, by the way, should stylistically be written > > x = x + 1 > yes I was wondering what "x=x+1" meant until you translated it... oh, "x = x + 1" of course! I thought to myself. Oh wait no I'm sarcastic. -- http://mail.python.org/mailman/listinfo/python-list
Re: Emacs vs. Eclipse vs. Vim
I would never tell someone what editor to use in the same way I wouldn't tell someone what religion to believe in. Which is to say, I would tell my kids or other trusting soul... I used emacs for years, I was eventually convinced to start using nedit, which is quite nice. For an IDE, which I need for GUI debugging more than all the other sometimes-nice bells and whistles, I use WingIDE and have found it pretty cool but not free. In terms of using it, it's much like any IDE these days and I think learning one is a good platform for learning how IDEs tend to work in general, at least until something genuinely different comes along in that space. I would say a beginner willing to face a learning curve should make sure they know how to edit their project outside of the IDE, understand something about how the IDE makes their project, and so on. -- http://mail.python.org/mailman/listinfo/python-list
Re: HELP!...Google SketchUp needs a Python API
> Just remember thought that if you threat Python like a > hammer, suddenly everything will look like a bail. > don't you mean if you use Python like a pitchfork? -- http://mail.python.org/mailman/listinfo/python-list
Re: Confused about class relationships
what you have is a totally acceptable factory system. Not sure why you are using a generator, but that's another matter. I agree with the previous replies regarding inheritance... this is not a case for inheritance. You could, however, have Bar be a borg with the Bar factory built in as a class method to the Bar class itself if you want the whole job done by one component. Questions to lead to or away from that: will Engine every create things besides Bars? -- http://mail.python.org/mailman/listinfo/python-list
Re: How to modify a program while it's running?
On Dec 16, 10:25 am, Joe Strout wrote: > Here's my situation: I'm making an AIM bot, but the AIM server will > get annoyed if you log in too frequently (and then lock you out for a > while). So my usual build-a-little, test-a-little methodology doesn't > work too well. > > So I'd like to restructure my app so that it can stay running and stay > logged in, yet I can still update and reload at least most of the > code. But I'm not sure what's the best way to do this. Should I move > the reloadable code into its own module, and then when I give my bot a > "reload" command, have it call reload on that module? Will that work, > and is there a better way? > > Thanks, > - Joe yes you want reload. Design the high level part that knows how to log in to be able to reload the stuff that changes. My guess is that is the best way, though I wouldn't be surprised if there are other solutions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is slow
On Dec 14, 6:38 pm, cm_gui wrote: > hahaha, do you know how much money they are spending on hardware to > make > youtube.com fast??? > > > By the way... I know of a very slow Python site called YouTube.com. In > > fact, it is so slow that nobody ever uses it. less than they'd spend to implement it in C -- http://mail.python.org/mailman/listinfo/python-list
Re: I always wonder ...
this is one of the most subtle trolls I've ever read. you sir, are a master! On Dec 22, 7:53 am, [email protected] wrote: > ... shouldn't people who spend all their time trolling be doing something > else: studying, working, writing patches which solve the problems they > perceive to exist in the troll subject? Is there some online troll game > running where the players earn points for generating responses to their > posts? > > -- > Skip Montanaro - [email protected] -http://smontanaro.dyndns.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6, GUI not working on vista?
as a 20 year observer of microsoft, I have to say this is not amazing at all... and I do not mean that as a random put down of Microsoft. Microsoft often develops things in response to demand... but they don't always fit in their system well, and thus are not really used in the spirit of the demand... meanwhile, bullet items are added to many a software box and magazine review. I would not presume to know more that Microsoft about that as a business practice, but as an engineering practice, it speaks for itself. -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE Question
it's commercial, but I like WingIDE enough to recommend... I run it on Linux and Mac and it works well. -craig On Oct 15, 7:19 am, "Steve Phillips" <[EMAIL PROTECTED]> wrote: > Hi All, > I am just wondering what seems to be the most popular IDE. The reason > I ask is I am currently at war with myself when it comes to IDE's. It > seems like every one I find and try out has something in it that > others don't and viceversa. I am in search for the perfect IDE and > after many months of searching, I always come back to IDLE to do what > I need to do. I want to use Komodo badly but the one issue I have with > that is sometimes the auto-complete works and other times it doesn't. > Even if I carbon copy a script. > > Thanks in advance, > Steve P -- http://mail.python.org/mailman/listinfo/python-list
Re: dictionary
when I was a baby programmer even vendors didn't have documentation to throw out... we just viewed the dissassembeled opcodes to find out how things worked... we never did find out much but I could make the speak click, and we were happy with it. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to examine the inheritance of a class?
> > Developer. NOT User. I go around and around on this issue, and have ended up considering anyone using my code a user, and if it's a library or class system, likely that user is a programmer. I don't really think there is a strong distinction... more and more users can do sophisticated configuration which while not like what we do professionally as software engineers... is not fundamentally different that programming, making the distinction arbitrary. I think the issue here for the term "user" is that there are many kinds of user, many ways they can customize the system, and the programmer/developer is just one kind of user. No? -- http://mail.python.org/mailman/listinfo/python-list
Re: How to examine the inheritance of a class?
> Thank you, Chris. Class.__bases__ is exactly what I wanted to see. > And I thought I had tried isinstance(), and found it lacking -- but I > just tried it again, and it does what I hoped it would do. While isinstance is no doubt the proper way to access this information, you may have run into problems because that isinstance and ducktyping do not always work well together... because having a particular interface does not mean you inherited that interface. Checking __bases__ will not solve the problem either though, so best to use isinstance if you can and document what you do well enough to help people avoid breaking the assumptions of your system. not that you didn't know that... but I thought it was worth saying because I, at least, more and more do meta-class style techniques which unfortunately do not play well with certain methods of checking type. -cba -- http://mail.python.org/mailman/listinfo/python-list
Re: Structures
> > Care to say more about what they are, not what they're like? > I'm not the OP and I may be biased by C++, I can imagine the complaints when I say, classes are just structures with function members for working on the structure. -- http://mail.python.org/mailman/listinfo/python-list
Re: PYTHON WORKING WITH PERL ??
> article:http://www.linuxjournal.com/article/3882 interesting read, thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: PYTHON WORKING WITH PERL ??
> article:http://www.linuxjournal.com/article/3882 even if it is by Eric Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the instance reference of an object
> > If the assert statement fails (and it does), then no copy was made and > Python is not call-by-value. > > So Python is not call-by-value, and it's not call-by-reference, so ... > either Python doesn't exist, or it uses a different calling convention. > coming from C/C++ Python seemed to me call by reference, for the pragmatic reason you said, modificaitons to function arguments do affect the variable in the caller. The confusing part of this then comes when immutable objects are passed in. You still get a reference, but rather than complaining if you change the value of that parameter at might happen if immutible was "const" and the code was const- correct. Honestly I understand how this can change the callBy paradigm I don't see it that way (though I've duly remembers call-by-sharing and call-by-object) for communication purposes). I see it as a factor of the way variable names are rebound, that is, the "quirk" I remember is not about how entities are passed to functions, but the quirk of how python deals with modifications to "immutibles". That is, python lets you change object references pointing to immutibles, which looks like changing the value referenced, by rebinding. So is that objectionable? -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the instance reference of an object
On Nov 4, 11:06 am, Joe Strout <[EMAIL PROTECTED]> wrote: > On Nov 4, 2008, at 7:42 AM, Craig Allen wrote: > > > coming from C/C++ Python seemed to me call by reference, for the > > pragmatic reason you said, modificaitons to function arguments do > > affect the variable in the caller. The confusing part of this then > > comes when immutable objects are passed in. > > Yes, you stepped in the wrong direction right away and led yourself > into a morass of contradictions. > > The correct way to look at it is that a Python reference is like a C++ > pointer. C++ pointers are passed by value (unless you add & to ... > I'd be very interested in hearing whether, as a C/C++ user, the above > explanation is clear and makes sense to you. > joe, yes, it makes perfect sense. In my defense my priority was figuring out what was going on in terms of what happens passing in various types of arguments, rather than what things are called. Also, as a C/C++ programmer my perspective is that the program is the interpreter, and so I try to think what the interpreter is doing. This is ke because after 15 years of statically linked languages (no one calls them this any more due to dynamically linked libraries) you get used to things evaporating at compile time, the name "x" for a variable has no status as a real entity at run time. It is a name through which you communicate with the compiler only, the compiler has no need to represent it in the runtime program. I think a lot of this language history is based on terminology that does not have to consider this name as a real entity at runtime. When you consider the status of the entity "x" in "x=1" in python, it is a pointer, and python looks like pass by value. The need for a different name comes from the fact that using pointers ubiquitously like this leads to behavior much more like pass by reference. I'm open to pass-by-sharing, or pass-by-object, but neither is perticularly intuitive, not as obvious in meaning as pass-by-val or pass-by-reference (or call-by-xxx). I suppose I'd like pass-by-name as more a description, as "name" to me has a similar sense to pointer, at least in a language that preserves the name as a runtime entitity (making C/C++ languages which compile away names). What happens in python is clear to me, I think I understand what the program, CPython is doing... the language still needs to settle. Thanks for the reply, it does help me find a better way to discuss what I understand about python and calling mechanics in general. cheers, craig -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the instance reference of an object
> arguably even older than that to Lisp. > Firstly, thanks to those that have responded to my part in this debate, I have found it very informative and interesting as I have the entire thread. However, with regard to comments that I led myself astray, I want to reiterate the one thing I find determinably important in this... I did not go astray because I did not fret what the words meant and try to draw anything from that. I learned exactly what would happen when I passed arguments different ways, and I learned that well and accurately. Then I mused what to call it all. At no time was I astray because I think to really be astray would be to have a misunderstanding on what happens, not on what we call what happens. but I will concede that trying to use call-by-name is not a viable idea as it's yet another term that is already taken. I did not think too hard what the distinction is, and as far as I know it's as good a candidate for what we call it as anything else, but I certainly don't want to fight for the term. Whatever we call the passing semantics and methods in Python... it will not change what I understand about what happens with certain kinds of calls vs others. cheers. -- http://mail.python.org/mailman/listinfo/python-list
Re: duck-type-checking?
> This is better achived, not by littering the functional code unit with > numerous assertions that obscure the normal function of the code, but > rather by employing comprehensive unit tests *separate from* the code > unit. that doesn't seem to work too well when shipping a library for someone else to use... we don't have access to the caller's code that needs to be checked. I suppose if the intent is to have a true assert, that does nothing in shipped code, then you can argue that testing addresses some of the issues, but one, not all of them, specifically, not the part where the problem is ably reported, and two, I don't think we can assume assert meant that sort of assert macro in C which compiles away in release versions. Asserts also do not litter code, they communicate the assumptions of the code. I like the idea of a general duck-type assertion and would probably use that, especially since I also have arguments which can be multiple objects, each with their own interface but similar meaning... i.e. lower level file objects can be passed in, or my higher level abstraction of the same file. -- http://mail.python.org/mailman/listinfo/python-list
Re: duck-type-checking?
> since both are equally informative when it comes to tracing the faulty > assignment. > steve, they are not equally informative, the assertion is designed to fire earlier in the process, and therefore before much mischief and corruption can be done compared to later, when you happen to hit the missing attribute. -- http://mail.python.org/mailman/listinfo/python-list
Re: Official definition of call-by-value (Re: Finding the instance reference...)
> >> * Do all objects have values? (Ignore the Python > >> docs if necessary.) > > > If one allows null values, I am current thinking yes. > > I don't see a difference between a "null value" > and not having a value. > I think the difference is concrete... an uninitialized variable in C has no value, I'd say, because the value it will have is indeterminate, it will be whatever happens to be sitting at that location in memory, inconsistent. If that variable is initialized to some value representing "none", like NULL, then it has a consistent value of "none". There is no way to have an uninitialized variable in python, so they are always consistently set, so they always have values. ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the instance reference of an object
I've just come to the conclusion it's not possible to call functions in python, to do so is undefined and indeterminate, like dividing by zero. Henceforth no calling functions for me as clearly it's the devil's playground. -- http://mail.python.org/mailman/listinfo/python-list
Re: Opening for Python Programmer at Newport Beach
On Mar 3, 10:17 am, Cool Dude wrote: > Hello , > This is Aniket from Techclique, a New Jersey based software > development and IT consulting firm providing top quality technical and > software professionals on a permanent and contractual basis to > Government and commercial customer including fortune 500 companies and > most of states and federal governments. I am contacting you to see if > you are comfortable to the skills mentioned below, please forward > resume to this e-mail address [email protected] > > Python Programmer (someone with industry knowledge/asset mgt) > Location: Newport Beach, CA (Need Local) > Duration: 6+ months > Note: Communication MUST be perfect!, Plus submit with 3 professional > references > > Python programming skills (with web development and dynamically > generated charts/plots in particular) and working knowledge of Linux/ > UNIX Shell Scripts and SQL. > Knowledge of Python integration with C/C++ - a definite plus. > > Qualifications/Requirements > * 3+ years of Python programming on Linux/Unix platform; recent (2007) > required need programmer to write bot that doesn't multipost... please submit three references so I can check to see if you've ever multiposted on usenet. > * Programming skills building forms, lay-outs, charts, and graphing > required > * Designing, coding, and testing web based applications preferred. > * Strong organizational, oral and written communications skills > * High energy/self starter with the ability to work independently > within the firm*s demanding and highly focused environment > > Thanks & Regards, > Aniket > Techclique Inc. > Jersey City, NJ > Email: [email protected] > Yahoo IM : [email protected] > Contact No : 732-357-3844 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is lambda allowed as a key in a dict?
> I think the point is that function objects compare by object identity, > so the two lambdas you use above are not equal even though they have the > same code. it raises an interesting question about why doesn't it. I can think of practical answers to that, obviously, but in principle, if a function compiles to exactly the same byte code, you obviously do not need two copies of it, and like strings shouldn't an identical function have the same id? This is merely philosophical, I don't see the value in making this so (a slight optimizaton and perhaps better conformity to other python features), but I do think it's an interesting question. cheers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is python worth learning as a second language?
On Mar 9, 12:43 am, ZikO wrote: > Hi > > I hope I won't sound trivial with asking my question. > > I am a C++ programmer and I am thinking of learning something else > because I know second language might be very helpful somehow. I have > heard a few positive things about Python but I have never writen any > single line in python so I do not know this language at all. > > Do you think python would be good complementary language for C++? Do you > think it's worth learning it or let's say try Java? and how difficult it > would be for me if I know C++ pretty well I would say? > > Thanks I'm not even going to read the replies first because I have my own. I was a C and C++ programmer exclusively for over a decade. During that time I had a "whatever tool for the problem" approach to language selection but C++ continued to be the best for the sort of thing I was doing. During that time I continued to learn other languages at least enough to consider them. I appreciated the role of interpreted languages were filling, but also never felt comfortable in them. Python, imo, is an excellent language to learn as a C++ programmer. It is relatively easy to extend with C/C++ and so works together well. When you find yourself writing some configuration language, you'll be able to use python instead. Also, I have found that Python helped open my mind a bit about object orientation and to realize that while the compile-time decisions in C++ are great for the C/C++ linking model, and provides a certain sort of power and control, that it also really does (as many had complained to me) take a few blows at how you really want OO to work. So I love python's OO and things which can be done structurally in C++ (like metaclass programming) but with which the C++ syntax is not cooperative, and which is very much harder to safely extend modularity too (I could go into detail but why bother here, it's either already clear what I mean or isn't that important)... Finally, Python is a multiparadigmed language, like C++. It very much seems to believe in Bjarne's original trust the programmer outlook on languages. As a C++ programmer I enjoyed the responsibility and power of choosing one's paradigms at the outset of a project. Such choices are best made consciously, one learns a lot about their project and develops a lot of philosophical standards for the design and implementation by having to think first "what models and programming paradigms will we adopt". It makes you think what sort of code you will be writing often, and which idioms will be efficient and maintainable. Honestly, I've become more of a Python fan than I am really comfortable with... it can't be as good as I think. -craig -- http://mail.python.org/mailman/listinfo/python-list
Re: Ban Xah Lee
> There you go: a 30-second psychological diagnosis by an > electrical engineer based entirely on Usenet postings. Â It > doesn't get much more worthless than that... > > -- > Grant rolf but interesting post nonetheless. I have been really somewhat fascinated by AS since I heard of it about a decade ago. There are many among us, with interesting ideas, occasionally savant level insight into certain abstractions, which often they can not communicate but which lie there for those that can communicate or come to understand nonetheless. having said that, none of this forgives rudeness or implies people have to tolarate it due to a person's condition, or even due to trying to help them achieve their potential (and thus get something productive out of it ourselves as well)... that is, if you have these communications problems you have to realize it, thank god you are functional, and just that alone will help you communicate. me, also IANAP, also working from usenet and an asperger's book I read (and google)... -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is lambda allowed as a key in a dict?
On Mar 10, 1:39 pm, Paul Rubin <http://[email protected]> wrote: > Craig Allen writes: > > it raises an interesting question about why doesn't it. I can think > > of practical answers to that, obviously, but in principle, if a > > function compiles to exactly the same byte code, you obviously do not > > need two copies of it, and like strings shouldn't an identical > > function have the same id? > > Identical strings don't necessarily have the same id: > > >>> a = "a"*1000 > >>> b = "a"*1000 > >>> id(a),id(b) > (137143648, 137144680) > >>> a==b > True interesting, I thought they were supposed to. -- http://mail.python.org/mailman/listinfo/python-list
packaging
we have software we are putting into package form. So far, all the
code was in local py files and we imported between the modules as
you'd think. Now with the package ("ourpackage") we are addressing
how import affects the importing module.
if "ourpackage" __init__.py itself does regular imports of the key
modules, like "ourmodule" (containing class OurClass)... it's a bit of
a pain for the user.
one imports ourpackage, and then need to get OurClass from ourmodule
still, i.e.:
import ourpackage
inst = ourpackage.ourmodule.OurClass()
Instead, I think we want "import package" to preserve the sort of
namespace our loose python files provided, so:
import ourpackage
inst = ourpackage.OurClass()
I think the way to do this, and it seems a legit use of a somewhat
dangerous form of import, to in ourpackage's __init__.py do this:
from ourmodule import *
So that the second form works. If anyone has a comment on that I'm
interested, either that it won't work, or to contradict my idea that a
wildcarded import is appropriate in this place as we are trying to
fill a flattened namespace.
But the reason I'm asking is that it's also been suggested that we
should include everything in a single module, so, ourpython1.py and
ourpython2.py, etc, all get moved to ourpython.py. I very much
dislike that idea for various (probably obvious) reasons.
On the other hand I do want to adopt whatever are de facto standards
for this sort of thing (especially from the user pov but also from the
developer's)... so any comment are appreciated. I've been using
python for a few years now but this is the first time we are forming
it in the shape of a proper package.
cheers and thanks.
-craig
--
http://mail.python.org/mailman/listinfo/python-list
Re: packaging
> andrew thanks andrew, good advice, I should probably use that throughout our code. btw, hope the world is treating you well, long time no see... -craig -- http://mail.python.org/mailman/listinfo/python-list
Re: Beazley on Generators
this is great, thanks... we have used generators to create something akin to a cooperative tasking environment... not to implement multitasking, but to be able to control low level data processing scripts. These scripts, written as generators, yield control to a control loop which then can pause, resume, abort, or change the state of shared context objects which the script uses as it's input and output space. E.g. the control loop can see there is intermediate output which an operator (managing a data reduction pipeline) might want to see. I can see from the first few slide I need to understand this. It already seems clear that there are ways to improve our approach to what we have done, though the overall approach is solid and works well. anyway thanks. -- http://mail.python.org/mailman/listinfo/python-list
singletons
Hey, forgive me for just diving in, but I have a question I was thinking of asking on another list but it really is a general question so let me ask it here. It's about how to approach making singletons. Background: I've been programming in python seriously for about a year now, maybe a little longer depending how you count, and the system I am making is sophisticated enough that I've had to enter into a few idioms which were beyond my knowledge of python, and I had to do quick research and test my ideas with test code (which of course can miss subtle problems). Otoh, I have decades of programming experience now and wasn't totally without footing. I think I have a solution I like for creating something to act as a singleton but I'm curious what other's think. I have several classes in our system which need to act like singletons, they are libraries of data classifications, and other such libraries of configurations for the system which need to be global. The first thing I found searching for singleton, early in this project, trying to be a good citizen and find a decent idiom from the python community itself, knowing someone had mentioned "singleton" and "python" together at some point, was a recommendation to do this: (option 1) class TehLibrary(object): __single = None def __init__(self): if (TehLibrary.__single): raise AlreadyExistsException # or whatever This sucks because that means creation of the object has to be in a try block as a matter of course, something I promptly hid in a factory function, but still. But the way this worked made me realize that the Class itself is a full fledged object, quite instance-like from my C++ addled (I love you C++) perspective and it's single. If I can store that instance, I can make a class that shares member at the class level. The class doesn't even have to be a singleton exactly. (option 2) Therefore option two is a family of options where class level members can be used to share whatever needs to be shared, though strictly the class is not a singleton since multiple instances are created which merely share the data that should be single (say a big dictionary of configuration information the class manages). (option 3) I still wanted actual singletons and realized that since I had to create a factory function even in option 1, that I could use module level variables to control the behavior of those factories, which led me to realize I'm basically just using the module itself as a singleton. And this is sort of where I have arrived... when I import the modules it runs code to build up it's basic services, much like an object construction. It only runs once no matter how many times it's imported. When client code asks for the library that should be a singleton, it gets a singleton which has been stored in a module level variable. Anyone have any comments? Is there anything wrong, evil, or ugly about using a module this way, or am I correct to think that actually, this is a common approach in python. Is it pythonic? -- http://mail.python.org/mailman/listinfo/python-list
Re: singletons
I don't intend to do much subclassing of this, but of course, I'd rather not second guess the future and it's not hard to imagine we will come to some point that we need to do just that. Thanks for the ideas about repairing option one, which I'd given up, though the ideal is still that tl = TehLibrary() would always return the same object. -craig On Jul 16, 2:00 pm, castironpi <[EMAIL PROTECTED]> wrote: > On Jul 16, 5:20 pm, Craig Allen <[EMAIL PROTECTED]> wrote: > > > > > Hey, forgive me for just diving in, but I have a question I was > > thinking of asking on another list but it really is a general question > > so let me ask it here. It's about how to approach making singletons. > > Background: I've been programming in python seriously for about a year > > now, maybe a little longer depending how you count, and the system I > > am making is sophisticated enough that I've had to enter into a few > > idioms which were beyond my knowledge of python, and I had to do quick > > research and test my ideas with test code (which of course can miss > > subtle problems). Otoh, I have decades of programming experience now > > and wasn't totally without footing. I think I have a solution I like > > for creating something to act as a singleton but I'm curious what > > other's think. > > > I have several classes in our system which need to act like > > singletons, they are libraries of data classifications, and other such > > libraries of configurations for the system which need to be global. > > > The first thing I found searching for singleton, early in this > > project, trying to be a good citizen and find a decent idiom from the > > python community itself, knowing someone had mentioned "singleton" and > > "python" together at some point, was a recommendation to do this: > > > (option 1) > > > class TehLibrary(object): > >__single = None > >def __init__(self): > > if (TehLibrary.__single): > > raise AlreadyExistsException # or whatever > > > This sucks because that means creation of the object has to be in a > > try block as a matter of course, something I promptly hid in a factory > > function, but still. > > > But the way this worked made me realize that the Class itself is a > > full fledged object, quite instance-like from my C++ addled (I love > > you C++) perspective and it's single. If I can store that instance, I > > can make a class that shares member at the class level. The class > > doesn't even have to be a singleton exactly. > > > (option 2) > > Therefore option two is a family of options where class level members > > can be used to share whatever needs to be shared, though strictly the > > class is not a singleton since multiple instances are created which > > merely share the data that should be single (say a big dictionary of > > configuration information the class manages). > > > (option 3) > > I still wanted actual singletons and realized that since I had to > > create a factory function even in option 1, that I could use module > > level variables to control the behavior of those factories, which led > > me to realize I'm basically just using the module itself as a > > singleton. And this is sort of where I have arrived... when I import > > the modules it runs code to build up it's basic services, much like an > > object construction. It only runs once no matter how many times it's > > imported. When client code asks for the library that should be a > > singleton, it gets a singleton which has been stored in a module level > > variable. > > > Anyone have any comments? Is there anything wrong, evil, or ugly > > about using a module this way, or am I correct to think that actually, > > this is a common approach in python. > > > Is it pythonic? > > In option 1, you could use the __new__ method, and return the existing > instance if there is one, or, I believe, call __init__ on the > superclass. Alternatively, define your own 'create' method with the > @classmethod decorator, instantiate with ClassA.create( ), and return > any existing instance from there. The catch is you need to rely on > the discipline of not using the default instantiation syntax. > > In option 2, you would have to wrap the functions with the > @staticmethod decorator, and all instance methods would act on the > same object. > > Each of these have different consequences for inheritance, if that is > on the horizon in your project. -- http://mail.python.org/mailman/listinfo/python-list
Re: singletons
On Jul 16, 7:01 pm, Lawrence D'Oliveiro <[EMAIL PROTECTED] central.gen.new_zealand> wrote: > In message > <[EMAIL PROTECTED]>, Craig > > Allen wrote: > > ... the ideal is still that > > > tl = TehLibrary() would always return the same object. > >> class TehLibrary(object) : > > ... @classmethod > ... def __new__(self, cls) : > ... return self > > >>> s = TehLibrary() > >>> s == TehLibrary() > > True That's great, I simply didn't find that when looking. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: singletons
On Jul 17, 2:15 am, Uwe Schmitt <[EMAIL PROTECTED]> wrote: > On 17 Jul., 00:20, Craig Allen <[EMAIL PROTECTED]> wrote: > > > > > I have several classes in our system which need to act like > > singletons, they are libraries of data classifications, and other such > > libraries of configurations for the system which need to be global. > > ... > > > Is it pythonic? > > My approach in this situation is to use the Borg pattern instead > of singeltons. This is really pythonic, very simple and usefull. > > Look athttp://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531 > The german wikipedia shows another solution using > metaclasse:http://de.wikipedia.org/wiki/Singleton_(Entwurfsmuster)#Das_Borg-Pattern > > Greetings, Uwe thanks uwe, doing some searching I ran into the borg pattern this morning. Definitely relevant. Thanks again and all for the feedback, I feel much reassured about the options when this sort of thing is required. -- http://mail.python.org/mailman/listinfo/python-list
Re: singletons
On Jul 17, 9:04 pm, Paddy <[EMAIL PROTECTED]> wrote: > On Jul 16, 11:20 pm, Craig Allen <[EMAIL PROTECTED]> wrote: > > > Hey, forgive me for just diving in, but I have a question I was > > thinking of asking on another list but it really is a general question > > so let me ask it here. It's about how to approach making singletons. > > Hi Craig, > This might be good for a general background on Design Patters in > Python: > > http://uk.youtube.com/watch?v=0vJJlVBVTFg > > - Paddy. thanks for the link paddy, I'll watch it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Written in C?
it's clear to me that the perfect language should exist a priori, coming to being causa sui. Having to actually implement a language is disgusting and unnatural. -- http://mail.python.org/mailman/listinfo/python-list
when does the GIL really block?
I have followed the GIL debate in python for some time. I don't want to get into the regular debate about if it should be gotten rid of (though I am curious about the status of that for Python 3)... personally I think I can do multi-threaded programming well, but I also see the benefits of a multiprocess approach. I'm not so egotistical that I don't realize perhaps my mt programming has not been "right" (though it worked and was debuggable) or more likely that doing it right I have avoided even trying some things people want mt programming to do... i.e. to do mt programming right you start to use queues a lot, inter-thread asynchronous, non-blocking, communication, which is essentially the multi-process approach, using IPC (except that the threads can see the same memory when, in your special case, you know that's ok. Given something like a reader-writer lock, this can have benefits... but again, whatever. My question is that given this problem, years ago before I started writing in python I wrote some short programs in python which could, in fact, busy both my CPUs. In retrospect I assume I did not have code in my run function that causes a GIL lock... so I have done this again. I start two threads... I use gkrellm to watch my processors (dual processor machine). If I merely print a number... both CPUS are getting 90% simultaneous loads. If I increment a counter and print it too, the same, and if I create a small list and sort it, the same. I did not expect this... I expected to see one processor pegged at around 100%, which should sometimes switch to the other processor. Granted, the same program in C/C++ would peg both processors at 100%... but given that the overhead in the interpreter cannot explain the extra usage, I assume the code in my thread's run functions is actually executing non-serially. I assume this is because what I am doing does not require the GIL to be locked for a significant part of the time my code is running... what code could I put in my run function to see the behavior I expected? What code could I put there to take advantage of the possibility that really the GIL is not locked enough to cause actual serialization of the threads... anyone care to explain? -- http://mail.python.org/mailman/listinfo/python-list
Re: when does the GIL really block?
On Aug 1, 12:06 pm, Rhamphoryncus <[EMAIL PROTECTED]> wrote: > On Jul 31, 7:27 pm, Craig Allen <[EMAIL PROTECTED]> wrote: > > > > > I have followed the GIL debate in python for some time. I don't want > > to get into the regular debate about if it should be gotten rid of > > (though I am curious about the status of that for Python 3)... > > personally I think I can do multi-threaded programming well, but I > > also see the benefits of a multiprocess approach. I'm not so > > egotistical that I don't realize perhaps my mt programming has not > > been "right" (though it worked and was debuggable) or more likely that > > doing it right I have avoided even trying some things people want mt > > programming to do... i.e. to do mt programming right you start to use > > queues a lot, inter-threadasynchronous, non-blocking, communication, > > which is essentially the multi-process approach, using IPC (except > > that thethreads can see the same memory when, in your special case, > > you know that's ok. Given something like a reader-writer lock, this > > can have benefits... but again, whatever. > > > My question is that given this problem, years ago before I started > > writing in python I wrote some short programs in python which could, > > in fact, busy both my CPUs. In retrospect I assume I did not have > > code in my run function that causes a GIL lock... so I have done this > > again. > > > I start twothreads... I use gkrellm to watch my processors (dual > > processor machine). If I merely print a number... both CPUS are > > getting 90% simultaneous loads. If I increment a counter and print it > > too, the same, and if I create a small list and sort it, the same. I > > did not expect this... I expected to see one processor pegged at > > around 100%, which should sometimes switch to the other processor. > > Granted, the same program in C/C++ would peg both processors at > > 100%... but given that the overhead in the interpreter cannot explain > > the extra usage, I assume the code in mythread's run functions is > > actually executing non-serially. > > Try using sys.setcheckinterval(1) (or even larger), overriding the > default of 100. This will reduce the locking overhead, which might by > why you see both CPUs as busy. > > > I assume this is because what I am doing does not require the GIL to > > be locked for a significant part of the time my code is running... > > what code could I put in my run function to see the behavior I > > expected? What code could I put there to take advantage of the > > possibility that really the GIL is not locked enough to cause actual > > serialization of thethreads... anyone care to explain? > > The GIL is locked during *all* access to the python interpreter. > There's nothing pure python code can do to avoid it - only a C > extension that doesn't access python could. thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: when does the GIL really block?
On Aug 1, 2:28 pm, John Krukoff <[EMAIL PROTECTED]> wrote: > On Thu, 2008-07-31 at 18:27 -0700, Craig Allen wrote: > > I have followed the GIL debate in python for some time. I don't want > > to get into the regular debate about if it should be gotten rid of > > (though I am curious about the status of that for Python 3)... > > personally I think I can do multi-threaded programming well, but I > > also see the benefits of a multiprocess approach. I'm not so > > egotistical that I don't realize perhaps my mt programming has not > > been "right" (though it worked and was debuggable) or more likely that > > doing it right I have avoided even trying some things people want mt > > programming to do... i.e. to do mt programming right you start to use > > queues a lot, inter-thread asynchronous, non-blocking, communication, > > which is essentially the multi-process approach, using IPC (except > > that the threads can see the same memory when, in your special case, > > you know that's ok. Given something like a reader-writer lock, this > > can have benefits... but again, whatever. > > > My question is that given this problem, years ago before I started > > writing in python I wrote some short programs in python which could, > > in fact, busy both my CPUs. In retrospect I assume I did not have > > code in my run function that causes a GIL lock... so I have done this > > again. > > > I start two threads... I use gkrellm to watch my processors (dual > > processor machine). If I merely print a number... both CPUS are > > getting 90% simultaneous loads. If I increment a counter and print it > > too, the same, and if I create a small list and sort it, the same. I > > did not expect this... I expected to see one processor pegged at > > around 100%, which should sometimes switch to the other processor. > > Granted, the same program in C/C++ would peg both processors at > > 100%... but given that the overhead in the interpreter cannot explain > > the extra usage, I assume the code in my thread's run functions is > > actually executing non-serially. > > > I assume this is because what I am doing does not require the GIL to > > be locked for a significant part of the time my code is running... > > what code could I put in my run function to see the behavior I > > expected? What code could I put there to take advantage of the > > possibility that really the GIL is not locked enough to cause actual > > serialization of the threads... anyone care to explain? > > -- > >http://mail.python.org/mailman/listinfo/python-list > > It's worth mentioning that the most common place for the python > interpreter to release the GIL is during I/O, which printing a number to > the screen certainly counts as. You might try again with a set of loops > that only increment, and don't print, and you may more obviously see the > GIL in action. > -- > John Krukoff <[EMAIL PROTECTED]> > Land Title Guarantee Company thanks, good idea, I think I'll try that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is my thinking Pythonic?
generally, I name the members in the Class definition and set them to None there... class Car: speed = None brand = None def __init__(): self.speed = defaultspeed #alternately, and more commonly, get this speed as a initializer argument self.brand = defaultbrand That solves the issue of being able to "see" all the members of an object by reading code... however, this all goes out the window when composing an instance dynamically (i.e. metaclass type stuff). -- http://mail.python.org/mailman/listinfo/python-list
Re: When to use try and except?
On Aug 29, 7:23 am, cnb <[EMAIL PROTECTED]> wrote: > If I get zero division error it is obv a poor solution to do try and > except since it can be solved with an if-clause. > > However if a program runs out of memory I should just let it crash > right? Because if not then I'd have to write exceptions everywhere to > prevent that right? well, recovering from an error can simply be telling the user what happened before bailing, so given that a program out of memory is going to fail, that doesn't mean you shouldn't catch the error and fail more gracefully. Of course, memory is a particularly hard example because you may not have memory to be preparing output... > So when would I actually use try-except? > > If there can be several exceptions and I just want to catch 1 or 2? > Like > try: > blahaba > except SomeError: > do something -- http://mail.python.org/mailman/listinfo/python-list
Re: How to record audio from Python on Mac?
I want to do this as well, and also some other audio processing via python. I have not tried yet, but much of my research points to pyaudio, PortAudio bindings for python, which is supposed to be multi- platform including Mac OS X, but as I say, I've not tried it yet. Related to this are some examples that get the audio data into numpy arrays for signal processing work. cheers, I'm interested to hear how any of this works out, I'm trying to start a python audio project in the next couple months. cheers. On Sep 9, 1:06 am, [EMAIL PROTECTED] wrote: > (I asked this on pythonmac-sig a couple days ago but got no response, so I'm > casting a broader net.) > > Can I easily control audio record/playback from Python on my Mac? I know > zip about audio recording or about Apple APIs via Python. Pointers to > simple examples would be much appreciated. > > Thanks, > > Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding environment variables to bash.
On Sep 11, 10:25 am, nntpman68 <[EMAIL PROTECTED]> wrote:
> >> doesn't exactly work for Python scripts, though:
>
> >> $ cat env.py
> >> #!/usr/bin/env python
> >> import os
> >> os.environ["TEST"] = "hello"
>
> >> $ . ./env.py && env | grep TEST
> >> import: unable to open X server `'.
> >> bash: os.environ[TEST]: command not found
>
> >>
>
> There's two options for the desperate ones.
>
> 1. Assuming the python script doesn't want to print anything useful
> =
>
> the python script just prints the exoprt commands and is
> being called via backticks from a shell code snipped being sourced with .
>
> # mypythonfile.py
> #!/usr/bin/env python
> value = myfavourite_python_function()
> print 'export ENV_VAR="%s"' ^ value
> #--- end of file --
>
> #- my_wrapper_file.sh --
> `./mypythonfile.py`
> # file end
>
> and then you call
> . ./my_wrapper_file.sh
>
> 2._ Pytho script wants to display something and set a variable
> ===
>
> a file being invoked with . calls the python script (which will create a
> small file with variables to be set).
> then this created file is being sourced
>
> # mypythonfile.py
> #!/usr/bin/env python
> value = myfavourite_python_function()
> file('my_export_commands.sh','w').write('export ENV_VAR="%s"\n' % value)
> #--- end of file --
>
> #- my_wrapper_file.sh --
> ./mypythonfile.py
> . ./my_export_commands.sh
> # file end
>
> bye
>
> N
>
> Fredrik Lundh wrote:
> > John Lawrence wrote:
>
> >> You can make a command use the current shell though if you use the '.'
> >> command e.g.:
>
> >> jl > cat env.sh
> >> export TEST='hello'
>
> >> jl > ./env.sh && env | grep TEST #Doesn't set TEST in parent
> >> shell
> >> jl > . ./env.sh && env | grep TEST #Adding '. ' before the
> >> command uses the same shell
> >> TEST=hello
>
> > doesn't exactly work for Python scripts, though:
>
> > $ cat env.py
> > #!/usr/bin/env python
> > import os
> > os.environ["TEST"] = "hello"
>
> > $ . ./env.py && env | grep TEST
> > import: unable to open X server `'.
> > bash: os.environ[TEST]: command not found
>
> >
oooh, clever but also... teh evil! Ok not evil, but teh not-pretty.
But you did say "for the desperate" so good on you. cheers.
--
http://mail.python.org/mailman/listinfo/python-list
Re: What do you call a class not intended to be instantiated
> Snce when are "users" ever involved > in programming problems or programming > languages ? > since the begining, the first users are programmers, users of your libraries. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
It is clear to me that Python is a multiparadigmed object oriented language. It is clearly possible to write procedural code... that is, Python does not force object oriented syntax or concepts on you and insist you define everything in such a structure. Is the OO it allows full OO, I think so, and the only way to argue otherwise I think is to point out that the "main" function is just the module level itself, and is not part of an object... which is just the sort of pedantic things purists like to hang their hat on. personally I am very much the sort that believe in "trust the programmer" and likes languages that provide a freedom to use various complementary paradigms, in the style of C++. Compared to that, it's clear that Python is quite object oriented even in the sense of drawing you to build things in object oriented ways... just not strictly requiring it. Which is good, it allows some interesting patterns which play quite well with object oriented desirgn (i.e. module as singleton)... in fact, that plays so well as a singleton, some would say the module is just an object anyway, and indeed, the intepreter tends to agree. So python may turn out to be pure OO, where Objects SIMULATE procedural programming paradigms and allow that paradigm as a result, on top of OO. cheers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
> if they want to, but it is *fully* OO in that it includes everything > required to do OO. But maybe the original blogger meant by "fully OO" > what I mean by "Pure OO"? it seems to me this is what was meant... pure OO, AND forced to use it. My personal feeling is that python is multiparadigmed and I'm more than fine with that. BUT, I am going to hold onto what I've noticed which is that Python seems to use OO deeply, well into the interpreter, and that the procedural styles available at the Python source level pretty much are built on top of this OO model, given you accept a module as an object, which it seems to be within the source code... but in the end, it's just words and the most important thing is that python is a tool you can use to make a computer do what you want, and whatever you call it may just be a distraction. cheers. -- http://mail.python.org/mailman/listinfo/python-list
Re: What do you call a class not intended to be instantiated
> > > Usegrammers? > usegrammers are just those that use grammars, but misspell it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why are "broken iterators" broken?
I'm interested what others think of this because at first I couldn't get it... I have an object which can iterate over its parts... and at first I thought, what? I'm supposed to create a new object every time the user needs to iterate the contents? In the end I interpreted that statement as if "unless __iter__()" is called again, in which case it makes sense that an iterator should stay "finished" until it's told to start to iterate again. Then even the stream analogy holds, you don't expect a stream to say EOF then start giving you bytes (from beyond the end, I guess)... instead, such a stream would more likely block if it got to the end of available data. I'm probably being stupid in this... perhaps I'm the only one that at first interpreted the phrase as being regardless of a fresh call to __iter__()... and that the OP was worried about some other implication. But if I was wrong to think it's ok for one and the same iterator to reset when __iter__() is called again, then I seriously don't understand. what does "forever" mean in that dictum? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python style: exceptions vs. sys.exit()
> The > question is: should the library function be able to just dump to > sys.exit() with a message about the error (like "couldn't open this > file"), or should the exception propagate to the calling program which > handles the issue? > my view is that the exceptions are there precisely to tell the calling program about the error and give the programmer a chance to do something smart about it. A library, properly, doesn't even know the context in which it is running, and sys.exit() is pretty heavy handed for a library to call and shows assumptions beyond what a library should assume about its running environment. imho -- http://mail.python.org/mailman/listinfo/python-list
Re: Python style: exceptions vs. sys.exit()
> Why, yes, I am wearing my BOFH hat. How could you tell? > > -- > Tim Rowe evil, but I think you may be a BSEFH, not a BOFH. -- http://mail.python.org/mailman/listinfo/python-list
