Re: Python editor/IDE on Linux?
On Apr 13, 6:20 pm, "Jack" <[EMAIL PROTECTED]> wrote: > I wonder what everybody uses for Python editor/IDE on Linux? > I use PyScripter on Windows, which is very good. Not sure if > there's something handy like that on Linux. I need to do some > development work on Linux and the distro I am using is Xubuntu. Try Scribes: Flash Demo: http://scribes.sf.net/demo.htm It's writing in Python and can extended with Python plugins. -- http://mail.python.org/mailman/listinfo/python-list
[Announce] Scribes 0.3.1 Released
Scribes is python editor for *nix and GNOME that balances simplicity with power. This release features extensibility via Python plugins, auto-completion enhances, snippets improvement, automatic replacement and correction, a new minimalist interface, performance optimizations and more... release note: http://scribes.sourceforge.net/release-note-0-3-1.html Flash Demo: http://scribes.sf.net/demo.htm GIF Demo: http://www.minds.may.ie/~dez/images/blog/scribes.html download: http://scribes.sf.net/download.html templates: http://scribes.sf.net/templates.tar.bz2 website: http://scribes.sf.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Conditional iteration
This why I prefer functional programming constructs for my list/sequence processing needs. is_true = lambda x: x > 0 map(process_list, filter(is_true, [-2, -1, 0, 1, 2, 3, 4])) at wrote: > I would like to spark the discussion about the following syntax problem I > encounter. > > THE PROBLEM > > I have a lot times the following code: > > for x in [-2, -1, 0, 1, 2, 3, 4]: > if x > 0: > ... more code... > > > It is not the addional line containing 'if x > 0:' that bothers me, but the > additional indentation. > > > THE SOLUTION > > More pythonic in view would be: > > for x in [-2, -1, 0, 1, 2, 3, 4] if x > 0: > ... more code ... > > > This blends basically > > [x for x in [-2, -1, 0, 1, 2, 3, 4] if x > 0] > > and > > x = y if x > 0 else 10 > > > EXTENDING > > And maybe a few usefull variants, like: > > for x in [-2, -1, 0, 1, 2, 3, 4] if x > 0 else -x: > ... more code ... > > In this case x will be 2, 1, 0, 1, 2, 3, 4. -- http://mail.python.org/mailman/listinfo/python-list
Re: One module per class, bad idea?
Matias Jansson wrote: > I come from a background of Java and C# where it is common practise to have > one class per file in the file/project structure. As I have understood it, > it is more common practice to have many classes in a Python module/file. > What is the motivation behind it, would it be a bad idea to have a guideline > in your project that promotes a one class per file structure (assuming most > of the programmers a background similar to mine)? It's a good idea. And I encourage it in my project. It makes sense for us because we document classes and methods copiously. However, use whatever works for your project. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paddy wrote: > Robert Uhl wrote: > > > Steven D'Aprano <[EMAIL PROTECTED]> writes: > > > > > > Speaking as somebody who programmed in FORTH for a while, that doesn't > > > impress me much. Prefix/postfix notation is, generally speaking, more > > > of a pain in the rear end than it is worth, even if it saves you a > > > tiny bit of thought when pasting code. > > > > Of course, you use prefix notation all the time in Python: > > > > for x in range(0,len(y)): > > dosomething(x) > > In Python, most containers are directly iterable so we are much more > likely to arrange our program to use: > for a in y: > dosomethingwith(a) > > -Paddy. Or the more succinct Python (FP) construct: map(dosomething, y) -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bill Atkins wrote: > Well, for example, "Lisp uses a fully-parenthesized notation for > writing programs" and "Python has significant whitespace" are both > objective facts. Agreed? There's nothing subjective about those two > facts. Do any of your points approach that level of objectivity? I believe so. Even though I wasn't trying to be. > What experience is this? Experience working with Scheme code in a project a few years back. > Macros are not a substitute for libraries, nor are libraries a > substitute for macros. Having macros lets you build more powerful and > more expressive libraries. > And not having them helps you build less powerful and expressive libraries? > > specialized libraries route. Meta-programming just doesn't tickle my > > fancy. It just spells maintainance nightmare. > > So it's not just macros but metaprogramming as a whole that bothers > you? You must have an enjoyable time writing programs. In Python, yes. > > >> And Lisp environments all support getting the macroexpansion, > >> documentation, and source of any unfamiliar macro you might happen > >> upon, so really this is not as much of a problem as you might > >> fantasize it to be. > > > > How's this a good thing? I don't need a Python environment to grok > > Python code. > > Nor do you need it to grok Lisp code. The environment is there to > make your life better. I was merely responding to your original claim > that it's impossible to make sense of code that uses macros. > Not impossible, just painstaking. > Hmm. Anecdotal evidence about Scheme (a vastly and fundamentally > different language from Common Lisp). Again, you've clinched it for > me. > I don't believe my experience would have been marginally different had I used Common Lisp. > I do believe that the "squealing and whining about macros" was a > response to Pythonistas claiming that macros are not useful. This was > in turn in response to a foolishly (trollishly?) cross-posted > question. It is not as if we have invaded your newsgroup. Pythonistas are not saying macros are not useful. They are saying their usefulness in overrated, exaggerated and needless in the context of Python. They are saying they don't see what they are missing and along with the rest of the world couldn't give a damn whether or not it is ever implemented in Python. Okay, I can't speak for all Pythonistas, but that's what I'm saying. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
John Thingstad wrote: > You are just being silly. > Lisp's OO environment CLOS is vastly superior to Python classes. > Both in terms of expressive power and flexibility. > You might even find out if you ever learnt how to use it. > Donkeys have wings. > In the windows world the best way to access system libraries are > via .NET. Thus each language inventing it's own libraries is quickly > becoming You're only proving my point. Why do you think most windows developers use .NET? > Python is fine if you approach programming as Lego, simply gluing together > libraries. You mean it's fine for what 90% of programmers do? > But if you want to do some serious algorithmic's you may find that it is > just to slow. Slow for users who aren't familiar with Psyco, Pyrex and C extensions, sure. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bill Atkins wrote: > Are any of these not subjective? Objectivity is in the eye of the beholder. > Lisp is much more than a functional language. Maybe so. But I've only ever appreciated its functional aspects. I wouldn't choose Lisp or its derivatives for OO related tasks even if I'm high. > Uh huh. Can you cite examples of this? Sounds like you're just > making stuff up here. Contrary to popular belief, writing a Lisp > macro that warps your mind and introduces a totally un-CL-like > semantics is extremely difficult. Most of the people who are good > enough at CL to do it (I'm certainly not one of them) are also > experienced enough to know when it's the right choice. Any sizable Lisp applications will make extensive use of macros. Emacs and magic ( the web framework) come to mind. My experience has shown that nobody but the person who writes the DSL extension can maintain their code. The benefits of extending a language in a domain specific manner are exaggerated. My observation is that macros are important to Lisp and it's derivative because they lack libraries to begin with. Common problems solved using macros in Lisp and friends are solved using specialized libraries in most other languages. And I like the specialized libraries route. Meta-programming just doesn't tickle my fancy. It just spells maintainance nightmare. > And Lisp environments all support getting the macroexpansion, > documentation, and source of any unfamiliar macro you might happen > upon, so really this is not as much of a problem as you might > fantasize it to be. How's this a good thing? I don't need a Python environment to grok Python code. > I don't agree with a lot of what you say in this paragraph, but I > you're right that libraries are crucial. That's why I wish there were > more people writing Lisp libraries instead of being scared away by > sheer fabrications like the stuff that's appearing in this thread. People only contribute to things they understand and appreciate. More people would be writing Lisp libraries if it was worthwhile. Apparently, it doesn't seem to be. A few years ago, I tried to write an editor is Scheme. The experience was appalling. I was able to write a fully functional prototype editor in less than a week in Python. Shockingly, at the time, I had no experience in Python. Guess which community I was inclined to contribute to afterwards. I hear stories similar to mine time and again, yet the Lisp community won't take heed. They'd rather squeal about the superiority of macros and whine about their frustrations in Python news groups. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Mark Tarver wrote: > How do you compare Python to Lisp? What specific advantages do you > think that one has over the other? > > Note I'm not a Python person and I have no axes to grind here. This is > just a question for my general education. > > Mark Advantages of Python: 1). More and better mature standard libraries (Languages don't matter, libraries do). 2). Multiple programming paradigms (including functional style programming see itertools, functools, operator modules (lambda, map, filter, reduce, sum etc builtins), higher order functions, list comprehension, blah, blah) 3). Better OO implementation. (I used to hate OO until I started using Python) 4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff said. Bindings for almost any lib worth using, at least on *nix) 5). Clearer syntax. 6). Better namespace management. (nobody ever talks about this, but Python seems to be one of the few languages that gets symbol management right from a users perspective) 7). Easier packaging and distribution system. 8). Ubiquity! Python is everywhere. Lisp, bleh. 9). Relatively good docs (PHP has better). 10). Fewer perceived community assholes. Large community. 11). Less fragmentation. Advantages of Lisp: Learning a functional language can improve your programming range and depth. And today, I wouldn't even recommend Lisp (it's rather archaic), when there's mind bending Haskell. I'd go as far as saying I believe Haskell has a better fate than Lisp. On Lisp Macros: I think they are overrated, and in general cause more harm than good. It's the reason I find Lisp-like programs difficult to grok, maintain and extend. Cos every smart ass wants to needlessly write his own mini language to the point of absolute obfuscation. Naturally, I'm supposed to be awed by his mischievous cleverness. Conclusion: The semantics or features of a language is almost irrelevant today. Developers want to put the lego pieces together, they don't want to make lego. Rewriting the sun and moon, or needlessly reinvent the wheel was popular in the 70s, but it's boring and expensive today. Today, when a developer needs to solve a problem, the question they ask is, "Is there a library for that?". If the answer is no, they a more likely to switch to a language that provides a library that solves their problem. The challenge for developers today is software architecture, robustness and scalability, not language purity or semantics. The Lisp, and to an extent Haskell, community will never ever ever grok this. They'll continue to wonder why an "inferior" language like Python keeps getting popular. It will always escape them that it might be because Python is actually easier to use for most people to write "real world" applications. It has good usability. -- http://mail.python.org/mailman/listinfo/python-list
ANNOUNCE: Scribes 0.3 Released
I am pleased to release version 0.3 of Scribes. Scribes is a text editor that uniquely balances simplicity with power. This release is a significant milestone in providing you with an enjoyable text editing experience. Bugs were squashed, new features implemented, countless enhancements made and numerous performance optimizations tweaked. It is strongly recommended that you upgrade to the new version. release note: http://scribes.sourceforge.net/release-note-0-3.html Flash Demo: http://scribes.sf.net/demo.htm GIF Demo: http://www.minds.may.ie/~dez/images/blog/scribes.html download: http://scribes.sf.net/download.html templates: http://scribes.sf.net/templates.tar.bz2 website: http://scribes.sf.net/ donate: http://scribes.sf.net/donate.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Help me use my Dual Core CPU!
Paul Rubin wrote: > "mystilleef" <[EMAIL PROTECTED]> writes: > > I use D-Bus (Python). I recommend it. I don't know how cross platform > > it is. However, it supports message passing of most built-in (strings, > > ints, lists, dictionaries etc) Python objects accross processes. You > > can mimick clean Erlang-like concurrency with it. It is the future of > > IPC on Desktop Unix. Given Python's crippled threading implementation, > > it can play a role in making your Python applications scalable, with > > regards to concurrency. I am recommending D-Bus because I have used it, > > and I know it works. I didn't read this of a newsgroup or mailing list. > > It looks useful, but as far as I can tell, it's just another IPC > thingie that works through sockets, sort of like pyro without the > remote objects. I don't see how it's related to Erlang-like > concurrency (which means ultralightweight coroutines, not heavyweight > Unix or Windows processes). I think Python concurrency schemes get > interesting when they at least share memory (like POSH). Otherwise I > think of them more as "distributed" than "concurrent". I always forget to bring up Stackless Python in this kinda discussions. I haven't used, but I plan porting one of my projects to it. http://www.stackless.com/about/sdocument_view -- http://mail.python.org/mailman/listinfo/python-list
Re: Help me use my Dual Core CPU!
Paul Rubin wrote: > "mystilleef" <[EMAIL PROTECTED]> writes: > > I use D-Bus (Python). I recommend it. I don't know how cross platform > > it is. However, it supports message passing of most built-in (strings, > > ints, lists, dictionaries etc) Python objects accross processes. You > > can mimick clean Erlang-like concurrency with it. It is the future of > > IPC on Desktop Unix. Given Python's crippled threading implementation, > > it can play a role in making your Python applications scalable, with > > regards to concurrency. I am recommending D-Bus because I have used it, > > and I know it works. I didn't read this of a newsgroup or mailing list. > > It looks useful, but as far as I can tell, it's just another IPC > thingie that works through sockets, sort of like pyro without the > remote objects. I don't see how it's related to Erlang-like > concurrency (which means ultralightweight coroutines, not heavyweight > Unix or Windows processes). I think Python concurrency schemes get > interesting when they at least share memory (like POSH). Otherwise I > think of them more as "distributed" than "concurrent". What is revolutionary about Erlang's concurrency model isn't exactly its light weight threads (Python already has a frame work that implements something similar) but the fact that in Erlang each thread behaves like a process and each thread communicates with each other via message passing. In Erlang, threads do not share state information. So all the limitations associated with concurrent programming in other mainstream languages are absent in Erlang. Because threads behave like processes and do not share state, Erlang allows you to create thousands of threads easily without the drawbacks of thread locks. Each thread or process manages its own state. Erlang then provides a protocol to allow each thread to communicate with each other. You can mimic this concept with a light weight event based IPC like D-Bus. D-Bus supports message passing and signals. It also provides you with an easy protocol that allows processes to talk to each other. You are right when you say that D-Bus uses heavy processes while Erlang uses light ones. But the robustness and scalability of Erlang's concurrency model stems from the fact that Erlang's threads are not really threads, but light weight processes that do not share state information. In brief, Erlang's concurrency model is basically IPC programming with light-weight processes. This is what I say you can mimic with D-Bus albeit, unfortunately, with heavy-weight processes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help me use my Dual Core CPU!
I use D-Bus (Python). I recommend it. I don't know how cross platform it is. However, it supports message passing of most built-in (strings, ints, lists, dictionaries etc) Python objects accross processes. You can mimick clean Erlang-like concurrency with it. It is the future of IPC on Desktop Unix. Given Python's crippled threading implementation, it can play a role in making your Python applications scalable, with regards to concurrency. I am recommending D-Bus because I have used it, and I know it works. I didn't read this of a newsgroup or mailing list. http://www.freedesktop.org/wiki/Software/dbus Simon Wittber wrote: > I've just bought a new notebook, which has a dual core CPU. > > I write cross platform games in Python, and I'd really like to be able > to use this second core (on my machine, and on user's machines) for any > new games I might write. > > I know threads won't help (in CPython at least) so I'm investigating > other types of concurrency which I might be able to use. I really like > the PyLinda approach, however I need to be able to pass around all the > simple python types, which PyLinda won't help me with. Also, PyLinda is > more focused on distributing computing; I really only want to have 2 > processes cooperating (or 4, if I had 4 CPUs/cores etc). > > Is there any cross platform way to share python objects across > processes? (I've found POSH, but it's old, and doesn't appear to be > maintained). I could implement my own object space using shared memory, > but from what I can see, this is not available on Win32. > > Are there any other concurrency options I've not discovered yet? > > > -Sw. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for the Perfect Editor
If you have those requirements installed, it does not need anything else. mystilleef wrote: > I recommend Scribes. > > http://scribes.sf.net > > Flash Demo: http://scribes.sf.net/snippets.htm > > GIF Demo: http://www.minds.may.ie/~dez/images/blog/scribes.html > > Omar wrote: > > I'd love the perfect editor that would be: > > > > a) free > > > > b) enable me to drag and drop code snippets from a sort of browser into > > the code > > > > c) can run programs right from within > > > > d) can edit > > - PYTHON > > - Javascript > > - HTML > > - actionscript (since I'm also learning flash) > > > > e) easy to learn > > > > suggestions? -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for the Perfect Editor
I recommend Scribes. http://scribes.sf.net Flash Demo: http://scribes.sf.net/snippets.htm GIF Demo: http://www.minds.may.ie/~dez/images/blog/scribes.html Omar wrote: > I'd love the perfect editor that would be: > > a) free > > b) enable me to drag and drop code snippets from a sort of browser into > the code > > c) can run programs right from within > > d) can edit > - PYTHON > - Javascript > - HTML > - actionscript (since I'm also learning flash) > > e) easy to learn > > suggestions? -- http://mail.python.org/mailman/listinfo/python-list
Re: threading support in python
You can use multiple processes to simulate threads via an IPC mechanism. I use D-Bus to achieve this. http://www.freedesktop.org/wiki/Software/dbus km wrote: > Hi all, > Are there any alternate ways of attaining true threading in python ? > if GIL doesnt go then does it mean that python is useless for > computation intensive scientific applications which are in need of > parallelization in threading context ? > > regards, > KM > --- > On 4 Sep 2006 07:58:00 -0700, bayerj <[EMAIL PROTECTED]> wrote: > > Hi, > > > > GIL won't go. You might want to read > > http://blog.ianbicking.org/gil-of-doom.html . > > > > Regards, > > -Justin > > > > -- > > http://mail.python.org/mailman/listinfo/python-list > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Editor
I recommend Scribes on Linux. It's simple, fast and powerful. Website: http://scribes.sf.net/ Flash Demo: http://scribes.sf.net/snippets.htm GIF Demo: http://www.minds.may.ie/~dez/images/blog/scribes.html JAG CHAN wrote: > Friends, I am trying to learn Python. > It will be of great help to me if you let me know which one would be best > editor for learning Python. > Plese note that I would like to have multiplatform editor which will be > useful for both LInux and Windows XP. > Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: text editor suggestion?
http://scribes.sourceforge.net/ Flash Demo: http://scribes.sourceforge.net/snippets.htm GIF Demo: http://www.minds.may.ie/~dez/images/blog/scribes.html Scribes is simple, slim, sleek and fast. It has no learning curve and conveys a no nonsense approach to text editing. You won't need to edit configuration files in lisp, read manuals or sacrifice your unborn grand daugther to the geek goddesses. It's also written in Python. Some people have described it as TextMate for Linux. Version 0.3 will be released in few days and will feature - remote editing - a document browser to show all files opened by the editor - recent files menu - more steriods... John Salerno wrote: > Ok, I know it's been asked a million times, but I have a more specific > question so hopefully this won't be just the same old post. I've tried a > few different editors, and I really like UltraEdit, but it's > Windows-only and I'm working more on Linux nowadays. > > Here are my criteria: > > 1. syntax highlighting (highly customizable) > 2. auto/smart indenting > 3. ability to run script > 4. light-weight text editor, not an IDE > 5. cross-platform (not really necessary, but nice) > > That's pretty much all I need. It's nice when you can customize a bunch > of other stuff too, but those are the most important. > > I've tried vim, but I really don't feel like taking the time to learn > how to use it, given that I just like to casually program (not to > mention that I prefer to use the mouse when navigating a document > sometimes). > > I also just started using Scite, and I really like it, except I find its > syntax highlighting to be very inflexible. You aren't able to define > your own groups of words -- you have to use what's given, basically. One > thing I like about UltraEdit is that you simply define as many groups of > keywords as you want and then assign a style to each one. Scite has a > very strange and rigid method of highlighting. > > So hopefully some of you might have some suggestions. My requirements > are minimal, but I'm still not happy with the syntax highlighting I'm > seeing in a lot of editors out there. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
>
> >>>>>>point 2 : so anyone *can* "illegimately tampering with an object's
> >>>>>>internal data" at will.
> >>>>>>
> >>>>>
> >>>>>And this is robust how?
> >>>>>
> >>>>
> >>>>You can do just the same in Java or C++.
> >>>>
> >>>
> >>>
> >>>OMG!
> >>
> >>It's common knowledge.
> >>
> > I ask how your solution is robust,
>
> This is definitively not a problem with "my solution". Python has *no*
> access restriction. Anyone can do what he wants with any attribute of
> your Python classes.
>
> > and you go off talking about Java
> > and C++.
>
> Whose access restriction is Joke.
>
> >
> >>>>>>point 3 : anyway it's not *my* system that will then crash - but the
> >>>>>>system of the one who "illegimately" played with my package's objects
> >>>>>>internals. And as far as I'm concerned, it's none of my problem - they
> >>>>>>were marked as implementation, so anyone playing with them is on it's
> >>>>>>own. FWIW, I suspect that if someone want to muck with implementation,
> >>>>>>he certainly has a good legitimate reason to do so, and will do her best
> >>>>>>to not break anything. Else he's a complete idiot and there's no cure
> >>>>>>for this.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>You can't be serious. Please tell me you are joking.
> >>>>
> >>>>I'm deadly serious and definitively not joking. There's no cure for
> >>>>idiocy, and there's definitively nothing like an idiot-proof system.
> >>>>
> >>>
> >>>Sure, but calling users idiots for as result of your laziness or poor
> >>>design or lack of robustness is equally idiotic.
> >>
> >>Ok, then 99.99% of Python programmers are lazy, have poor design skills
> >>and are unable to write a robust application. So they are idiotic too.
> >>
> > If you say so.
>
> Logical derivation from your above statement.
>
> >
> >>>>>>point 4 : since we have computed attributes, turning a "public data
> >>>>>>attribute" (to use your idiom) into a "private/protected data attribute
> >>>>>>with accessors" *without breaking the interface* is not even a
> >>>>>>non-brainer.
> >>>>>>
> >>>>>>Now, please, can you explain the difference between :
> >>>>>>
> >>>>>>class Complicated(object):
> >>>>>>def __init__(self, data):
> >>>>>> self.data = data
> >>>>>>def _get_data(self):
> >>>>>> return self._data
> >>>>>>def _set_data(self, data):
> >>>>>> self._data = data
> >>>>>>
> >>>>>>and
> >>>>>>
> >>>>>>class Pragmatic(object):
> >>>>>>def __init__(self, data)
> >>>>>> self.data = data
> >>>>>>
> >>>>>>
> >>>>>>and find any *valid* reason to use the first solution instead of the
> >>>>>>second ? ('that's what the book says' not being a valid reason).
> >>>>>>
> >>>>>
> >>>>>
> >>>>>I don't know it's your code not mine.
> >>>>
> >>>>IOW : you're unable to find any valid reason to use the second solution
> >>>>instead of the first (of course : there's none), but refuse to admit it.
> >>>>
> >>>
> >>>Hey, I didn't write that code. You did! You deal with it. My input on
> >>>__your__ code at this point is irrelevant.
> >>
> >>It's totally relevant, and you're still unable to come with any valid
> >>reason to prefer the first solution over the second. I'm totally
> >>confident that if there was *any* defendable reason to favor the first
> >>approach, you'd have chosen to answer instead of playing dumb.
> >>
> >
> > Chosen what answer? First of al
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Bruno Desthuilliers wrote: > > > (snip) > >>>>>You use accessors when you need to control access to a data attribute. > >>>> > >>>>Indeed. And when you don't need too ? (the second 'o' is not a typo) > >>>> > >>> > >>> > >>>You make the attribute private/protected. > >> > >>doh :( > >> > >>Let's talk about psychorigid mindset... > >> > > > > > > Thanks, I'm insane. > > You say so. > > (snip) > >>>>>>Then why do you advise "(making) all attributes of a class > >>>>>>private/protected" and systematically using properties ? > >>>>>> > >>>>> > >>>>> > >>>>>Because you don't want third parties illegimately tampering with an > >>>>>object's internal data and thus crashing your system? > >>>> > >>>>Let's try again... > >>>> > >>>>point 1 : there's *no* language-inforced access restriction in Python. > >>>>Just a *convention*. > >>>> > >>> > >>> > >>>Huh? What are properties for then? > >> > >>To allow attribute syntax when you really have computation behind. Which > >> 1/ let you start with the simplest case (a simple attribute) and change > >>your mind latter > >>2/ offer the possibility to use an attribute syntax (instead of a method > >>call syntax) when it seems more natural. > >> > > > > > > Right, and what I'm I trying to do again? > > > > Write Java in Python. > Dude, I haven't written more than "Hello World" programs in Java. I __don't__ have a strong Java background. > >>>>point 2 : so anyone *can* "illegimately tampering with an object's > >>>>internal data" at will. > >>>> > >>> > >>>And this is robust how? > >>> > >> > >>You can do just the same in Java or C++. > >> > > > > > > OMG! > > It's common knowledge. > I ask how your solution is robust, and you go off talking about Java and C++. Quit turning this into a language pissing contest. The hell I care what Java or C++ does. > > > >>>>point 3 : anyway it's not *my* system that will then crash - but the > >>>>system of the one who "illegimately" played with my package's objects > >>>>internals. And as far as I'm concerned, it's none of my problem - they > >>>>were marked as implementation, so anyone playing with them is on it's > >>>>own. FWIW, I suspect that if someone want to muck with implementation, > >>>>he certainly has a good legitimate reason to do so, and will do her best > >>>>to not break anything. Else he's a complete idiot and there's no cure > >>>>for this. > >>>> > >>> > >>> > >>>You can't be serious. Please tell me you are joking. > >> > >>I'm deadly serious and definitively not joking. There's no cure for > >>idiocy, and there's definitively nothing like an idiot-proof system. > >> > > > > Sure, but calling users idiots for as result of your laziness or poor > > design or lack of robustness is equally idiotic. > > Ok, then 99.99% of Python programmers are lazy, have poor design skills > and are unable to write a robust application. So they are idiotic too. > If you say so. > >>>>point 4 : since we have computed attributes, turning a "public data > >>>>attribute" (to use your idiom) into a "private/protected data attribute > >>>>with accessors" *without breaking the interface* is not even a > >>>>non-brainer. > >>>> > >>>>Now, please, can you explain the difference between : > >>>> > >>>>class Complicated(object): > >>>> def __init__(self, data): > >>>> self.data = data > >>>> def _get_data(self): > >>>> return self._data > >>>> def _set_data(self, data): > >>>> self._data = data > >>>> > >>>>and > >>>> > >>>>class Pragmatic(object): > >>>> def __init__(self, data) > >>>> self.data =
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Bruno Desthuilliers wrote: > > > >>mystilleef wrote: > >> > >>>Bruno Desthuilliers wrote: > >>> > >>> > >>>>mystilleef wrote: > >> > >>(snip) > >> > >>>>>>>Of course using setters for the sake of just using them is pointless. > >>>>>> > >>>>>>Indeed. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>The reason to use them is if pre-conditions or post-conditions need to > >>>>>>>be met. Or to control access to an objects states. > >>>>>> > >>>>>>Then why advocate *systematic* use of them ? > >>>>>> > >>>>>>(snip) > >>>>> > >>>>>I never advocated anything. > >>>> > >>>>You advocated > >>>>""" > >>>>1). Make all attributes of a class private/protected . > >>>>2). If a "non-callable" attribute is going to be used outside a class, > >>>>think about making it a property and name the property well, because > >>>>you never know... > >>>>""" > >>>> > >>> > >>> > >>>You use accessors when you need to control access to a data attribute. > >> > >>Indeed. And when you don't need too ? (the second 'o' is not a typo) > >> > > > > > > You make the attribute private/protected. > > doh :( > > Let's talk about psychorigid mindset... > Thanks, I'm insane. > > > >>>That's not advocacy, that's common sense. > >> > >>I'm afraid we don't use the same definition of "common sense". Writing > >>useless code is not part of my definition of "common sense". > >> > >>(snip) > >> > >>>>>I agree. And I already told you I think in terms of state and behavior > >>>>>and not language dependent semantics. > >>>> > >>>>Then why do you advise "(making) all attributes of a class > >>>>private/protected" and systematically using properties ? > >>>> > >>> > >>> > >>>Because you don't want third parties illegimately tampering with an > >>>object's internal data and thus crashing your system? > >> > >>Let's try again... > >> > >>point 1 : there's *no* language-inforced access restriction in Python. > >>Just a *convention*. > >> > > > > > > Huh? What are properties for then? > > To allow attribute syntax when you really have computation behind. Which > 1/ let you start with the simplest case (a simple attribute) and change > your mind latter > 2/ offer the possibility to use an attribute syntax (instead of a method > call syntax) when it seems more natural. > Right, and what I'm I trying to do again? > > > >>point 2 : so anyone *can* "illegimately tampering with an object's > >>internal data" at will. > >> > > > > And this is robust how? > > > > You can do just the same in Java or C++. > OMG! > >>point 3 : anyway it's not *my* system that will then crash - but the > >>system of the one who "illegimately" played with my package's objects > >>internals. And as far as I'm concerned, it's none of my problem - they > >>were marked as implementation, so anyone playing with them is on it's > >>own. FWIW, I suspect that if someone want to muck with implementation, > >>he certainly has a good legitimate reason to do so, and will do her best > >>to not break anything. Else he's a complete idiot and there's no cure > >>for this. > >> > > > > > > You can't be serious. Please tell me you are joking. > > I'm deadly serious and definitively not joking. There's no cure for > idiocy, and there's definitively nothing like an idiot-proof system. > Sure, but calling users idiots for as result of your laziness or poor design or lack of robustness is equally idiotic. > > > >>point 4 : since we have computed attributes, turning a "public data > >>attribute" (to use your idiom) into a "private/protected data attribute > >>with acce
Re: Accessors in Python (getters and setters)
Steve Holden wrote: > mystilleef wrote: > [...] > > > > I don't know it's your code not mine. > > > > class Robust(object): > > > > def __init__(self): > > # Arbitrarily changing this state to False will crash app or > > will > > # corrupt the whole event system. > > self.__is_active = True > > > > def get_is_active(self): > > return self.__is_active > > > > buffer_is_active = property(get_is_active, doc="True if buffer is > > editable") > > > Let's ignore changes of state for the moment. The mystical difference > that makes read access via > >some_robust.buffer_is_active() > buffer_is_active is not a method, it's a property. So: some_robust.buffer_is_active is appropriate. > acceptable and > >some_robust.__is_active > > somehow dangerous (ignoring the fact that name_mangling will take place) > is what? > We can't ignore name mangling. That's an illegal statement in Python. So it is less dangerous. > > def monitor_events(self): > > # Only methods of this class can change __is_active. > > # Add code to change __is_active here. > > return > > > I'm sure nobody would argue that if close synchronization between > multiple attributes is required then write accessors are a bad idea. But > using them unnecessarily just makes your code heavier, slower and less > easy to maintain. > Ah, I broke my own rule. That method is supposed to be private too. Meaning no one can change the state of the object except the object itself. The code is below def __monitor_event(self): # Perform whatever needs to be done to change state return __monitor_event is not supposed to be a write accessor. My point was show how you can change the state of an object internally without needing external access to it. Since some people are surprisingly claiming it is not possible. > > See! I'm controlling access. Whee! And if one sober morning I want to > > change the name __is_active to __buffer_is_active, I won't have to hunt > > down 27000 lines of code to do it. Also a naive third party won't crash > > my system by changing Robust's state arbitrarily. Because in the real > > world when your program is buggy, you get bug reports, nasty emails > > among other forms of ridicule. And your supposed solution to my problem > > is me saying, "but...but...I told you not change is_active." Ha! And if > > you can't figure out why anyone would do this, then I'm not wasting my > > time here anymore. Someday you'll learn the hard way. > > > It's way too late. My comments *are* based on engineering experience. > One day you may realise that unnecessary complexity is a far bigger time > waster than any imagined problems of direct attribute access. I suspect > that if you are getting complaints if the nature you describe it's just > because your software isn't that good. > And mine are based on future engineering predictions? Okay, one day I shall see the light. > > Thanks to the people who exposed me to Python's properties. > > > > Bye > > > Really? Promise? I fear we are arguing from different premises. > Yes, we are. We have been since about the 5th post on this thread if you haven't noticed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Steve Holden wrote: > mystilleef wrote, making me somewhat tired of his/her repeated inability > to get what's being said [sigh]: > > Bruno Desthuilliers wrote: > >>mystilleef wrote: > >>>Bruno Desthuilliers wrote: > >>>>mystilleef wrote: > >>>>>Gerhard Fiedler wrote: > >>>>>>On 2006-07-15 06:55:14, mystilleef wrote: > >>>>>>>In very well designed systems, the state of an object should only be > >>>>>>>changed by the object. > >>>>>> > >>>>>>IMO that's not quite true. Ultimately, the state always gets changed by > >>>>>>something else (user interaction, physical events); very few objects are > >>>>>>completely self-contained in their behavior. > >>>>>> > >>>>> > >>>>>Then in those cases the system becomes a victim of high coupling. > >>>> > This makes it somewhat obvious that you don't appear to fully understand > the concept of coupling as applied to software systems. > > >>>>Time to burn your book and face reality. ObjA sends message Msg1 to > >>>>ObjB. Part of the associated behaviour is that in responce to Msg1, objB > >>>>changes it's own state. Practical result : ObjB's state has been changed > >>>>by ObjA. Practical question : how do you hope to avoid this "hi > >>>>coupling" (lol), apart from making all your objects totally autistic ? > >>>> > >>>Are you serious? > >> > >>Deadly serious. But I'm afraid you're still missing the point. > >> > >>>Well, you design an object that serves as a mediator. > >>>All objects can then only interact with themselves and the mediator > >>>only. Via signals, objects learn to automatically adjust their states > >>>and respond to events. > >> > >>signal -> message -> method call -> change state. > >> > >>Spell it how you like, add as many indirection levels you want, it still > >>boils down to the fact that *something* triggers the state change. > >> > > Right! > > > If you implement an accessor to change a class's instances' states, > surely something has to call that accessor. You seem to be implying that > such calls can only be made from within other methods of the same > object, which (if true, which it isn't) would tend to leave each class > in a vacuum where nothing else can affect its instances. > > Of *course* objects are subject to external influences: since you like > the concept of coupling, how else could different components be coupled > at all? I gave the solution earlier. In well designed systems objects should be responsible for updating their state themselves. In essence, objects should learn to mind their own business. There will be some form of coupling, but it should be minimal. Preferably the only coupling permitted should be between an object and its mediator. Messages are passed through the system via signals or events or established protocols. What are the benefits? Well I can change the implementation of any object at will without breaking the whole system. Or I can even completely replace modules and objects with new ones without breaking the whole system. If you are dealing with large source code, this is a no brainer. And if you put a little effort into to it, you can create objects that know when to initialize and destroy themselves as well as update their states automatically. Welcome to event based programming. (snip) > >>>I'm sure glad I didn't burn my book. > >> > >>No comment. > >> > >>>>>>In most systems (and you possibly have written some of them) are objects > >>>>>>whose state gets changed by other objects -- possibly through the > >>>>>>intermediation of setter methods that do nothing else but set the state. > >>>>>>There's no conceptual difference between directly setting the state or > >>>>>>calling a setter function that does nothing else but directly setting > >>>>>>the > >>>>>>state -- except for one unnecessary level of indirection in the latter. > >>>>> > >>>>>It depends. If certain conditions need to be met before changing the > >>>>>state of an object, then arbitrarily changing it can be dangerous. > >>>> > >>>>Does this imply a 'method call' *syntax* ? > >>> > >>>
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> (snip)
> >>>>>
> >>>>>Of course using setters for the sake of just using them is pointless.
> >>>>
> >>>>Indeed.
> >>>>
> >>>>
> >>>>
> >>>>>The reason to use them is if pre-conditions or post-conditions need to
> >>>>>be met. Or to control access to an objects states.
> >>>>
> >>>>Then why advocate *systematic* use of them ?
> >>>>
> >>>>(snip)
> >>>
> >>>I never advocated anything.
> >>
> >>You advocated
> >>"""
> >>1). Make all attributes of a class private/protected .
> >>2). If a "non-callable" attribute is going to be used outside a class,
> >>think about making it a property and name the property well, because
> >>you never know...
> >>"""
> >>
> >
> >
> > You use accessors when you need to control access to a data attribute.
>
> Indeed. And when you don't need too ? (the second 'o' is not a typo)
>
You make the attribute private/protected.
> > That's not advocacy, that's common sense.
>
> I'm afraid we don't use the same definition of "common sense". Writing
> useless code is not part of my definition of "common sense".
>
> (snip)
> >>>
> >>>I agree. And I already told you I think in terms of state and behavior
> >>>and not language dependent semantics.
> >>
> >>Then why do you advise "(making) all attributes of a class
> >>private/protected" and systematically using properties ?
> >>
> >
> >
> > Because you don't want third parties illegimately tampering with an
> > object's internal data and thus crashing your system?
>
> Let's try again...
>
> point 1 : there's *no* language-inforced access restriction in Python.
> Just a *convention*.
>
Huh? What are properties for then?
> point 2 : so anyone *can* "illegimately tampering with an object's
> internal data" at will.
>
And this is robust how?
> point 3 : anyway it's not *my* system that will then crash - but the
> system of the one who "illegimately" played with my package's objects
> internals. And as far as I'm concerned, it's none of my problem - they
> were marked as implementation, so anyone playing with them is on it's
> own. FWIW, I suspect that if someone want to muck with implementation,
> he certainly has a good legitimate reason to do so, and will do her best
> to not break anything. Else he's a complete idiot and there's no cure
> for this.
>
You can't be serious. Please tell me you are joking.
> point 4 : since we have computed attributes, turning a "public data
> attribute" (to use your idiom) into a "private/protected data attribute
> with accessors" *without breaking the interface* is not even a non-brainer.
>
> Now, please, can you explain the difference between :
>
> class Complicated(object):
> def __init__(self, data):
> self.data = data
> def _get_data(self):
> return self._data
> def _set_data(self, data):
> self._data = data
>
> and
>
> class Pragmatic(object):
> def __init__(self, data)
> self.data = data
>
>
> and find any *valid* reason to use the first solution instead of the
> second ? ('that's what the book says' not being a valid reason).
>
I don't know it's your code not mine.
class Robust(object):
def __init__(self):
# Arbitrarily changing this state to False will crash app or
will
# corrupt the whole event system.
self.__is_active = True
def get_is_active(self):
return self.__is_active
buffer_is_active = property(get_is_active, doc="True if buffer is
editable")
def monitor_events(self):
# Only methods of this class can change __is_active.
# Add code to change __is_active here.
return
See! I'm controlling access. Whee! And if one sober morning I want to
change the name __is_active to __buffer_is_active, I won't have to hunt
down 27000 lines of code to do it. Also a naive third party won't crash
my system by changing Robust's state arbitrarily. Because in the real
world when your program is buggy, you get bug reports, nasty emails
among other forms of ridicule. And your supposed solution to my problem
is me saying, "but...but...I told you not change is_active." Ha! And if
you can't figure out why anyone would do this, then I'm not wasting my
time here anymore. Someday you'll learn the hard way.
Thanks to the people who exposed me to Python's properties.
Bye
--
http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Bruno Desthuilliers wrote: > > > >>mystilleef wrote: > >>Please don't top-post > >> > >>>On State and Behavior: > >>> > >>>To understand objects in terms of state and behavior you need to > >>>absolve yourself from implementation details of languages > >>>and think at an abstract level. > >> > >> > >> > >>>Take a button object, for example. It has state and behavior. Possible > >>>states may include, is_active, is_focused, is_mapped, etc. Behavior is > >>>what the button does when it responds to events, (e.g when you click on > >>>it, or drag it, or position a pointer over it.) If you've done any form > >>>of event based programming (GUI/Games/Simulation), this method of > >>>thinking becomes natural. > >>> > >>>As you can see, when I'm designing a button object, I don't care what > >>>Python does with is_active. I don't care how it accesses. I don't care > >>>what is_active means to Python. I don't care about Python's __get__ > >>>/__set__ special/latent functions or implementation details. is_active > >>>to me and every other developer is a state of the button object. And at > >>>that level that's all that matters. Python can tell me it's just ones > >>>and zeros for all I care. > >>> > >>>In very well designed systems, the state of an object should only be > >>>changed by the object. > >> > >>... as a response to a message. > >> > >> > >>>For example, a third party randomly changing > >>>is_active, (which Python lets you do freely and easily) > >> > >>Unless you make it a read-only property. > >> > > > > So you see the purpose of accessors then? > > *where* did I say *anything* that could *possibly* be taken as me not > seeing the point of computed attributes ? > > What I'm saying here is that it's totally useless to duplicate default > behaviour. > And who's doing that? > > > >>>from False to > >>>True may crash your GUI. > >> > >>>And I'm not making this up. Things like this > >>>do really happen depending on the whackyness of your toolkit. So > >>>sometimes, it is my duty to protect the state of an object. Especially > >>>if its state cannot afford to be corrupted rendering the system > >>>unstable. And situations like this are found a plenty in event based > >>>programming. Which is programming objects based almost entirely on > >>>state and behavior. As you can see this has nothing to do with Python > >>>vs Java's vs X's implementation of accessors and how using them sucks, > >>>or how they aren't Pythonic. Some domains just require this stuff. > >> > >>Properties *are* 'accessors'. > >> > > > > I never said they weren't. > > Fine. > > Now : in a language with support for computed attributes, direct > attribute access is the default r/w accessors. > Depends on your definition of accessors. Otherwise 97% of languages provide direct access to an object's data attributes. > > > >>>One of the requirements for designing robust object systems is ensuring > >>>the state of objects aren't easily contaminated. > >> > >>"contaminated" ??? > >> > > Make an object's state unreliable. See above example. > > That's the word you choose that I find really strange. > What's strange about it. If an object's data attribute is supposed to state that it is false when there are no mark objects in the buffer, and a third party accidently incorrectly changes the attribute to state it is True for whatever reasons, you essentially corrupt the objects state and render the whole system "unreliable," or "buggy". What again is difficult to grasp? > > > >>>That "state" is the > >>>objects data (read: stuff the object needs to do something "reliably"). > >> > >>Makes no sens to me. > >> > > > > is_active is an object's data, > > class Obj(object): > # > @apply > def is_active(): > def fget(self): > return (self.something and self.computeThis()) \ > or self.otherCondition() > def fset(self, val): > raise ReadOnlyError() > def f
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Bruno Desthuilliers wrote: > > > >>mystilleef wrote: > >> > >>>Gerhard Fiedler wrote: > >>> > >>> > >>>>On 2006-07-15 06:55:14, mystilleef wrote: > >>>> > >>>> > >>>> > >>>>>In very well designed systems, the state of an object should only be > >>>>>changed by the object. > >>>> > >>>>IMO that's not quite true. Ultimately, the state always gets changed by > >>>>something else (user interaction, physical events); very few objects are > >>>>completely self-contained in their behavior. > >>>> > >>> > >>>Then in those cases the system becomes a victim of high coupling. > >> > >>Time to burn your book and face reality. ObjA sends message Msg1 to > >>ObjB. Part of the associated behaviour is that in responce to Msg1, objB > >>changes it's own state. Practical result : ObjB's state has been changed > >>by ObjA. Practical question : how do you hope to avoid this "hi > >>coupling" (lol), apart from making all your objects totally autistic ? > >> > > > > > > Are you serious? > > Deadly serious. But I'm afraid you're still missing the point. > > > Well, you design an object that serves as a mediator. > > All objects can then only interact with themselves and the mediator > > only. Via signals, objects learn to automatically adjust their states > > and respond to events. > > signal -> message -> method call -> change state. > > Spell it how you like, add as many indirection levels you want, it still > boils down to the fact that *something* triggers the state change. > Right! > > This is just one of several methods you can > > dramatically reduce coupling. > > It's just one of several methods that dramatically increases complexity, > without changing anything to the fact that in the end, *practically*, > some object ObjA changes its state as a response to a message sent by ObjB. > Say that to game/simulation developers. > > I'm sure glad I didn't burn my book. > > No comment. > > > > >>>>In most systems (and you possibly have written some of them) are objects > >>>>whose state gets changed by other objects -- possibly through the > >>>>intermediation of setter methods that do nothing else but set the state. > >>>>There's no conceptual difference between directly setting the state or > >>>>calling a setter function that does nothing else but directly setting the > >>>>state -- except for one unnecessary level of indirection in the latter. > >>>> > >>> > >>> > >>>It depends. If certain conditions need to be met before changing the > >>>state of an object, then arbitrarily changing it can be dangerous. > >> > >>Does this imply a 'method call' *syntax* ? > > > > > > That's language dependent. > > > > > >>Given the existence of > >>"computed attributes" (ie: support for 'attribute access' *syntax* with > >>hidden accessors) and the possibility to redefine implementation (from > >>default attribute r/w access to computed/controlled) without touching > >>the interface, why advocate the *systematic* use of computed attributes > >>when it's just duplicating the default behaviour ? > >> > > > > > > I'm not advocating anything. > > cf below on this. > > > I'm just stating the use case for > > accessors and the wisdom behind them. My qualm with implicit accessors > > remains the name issue. > > The "name issue" is *your* problem. And AFAICT, it's a "problem" because > you refuse to free your mind from a "what's in the book" mindset. > What book are we talking about? > > > >>>>>For example, a third party randomly changing is_active, (which Python > >>>>>lets you do freely and easily) from False to True may crash your GUI. > >>>>>And I'm not making this up. Things like this do really happen depending > >>>>>on the whackyness of your toolkit. > >>>> > >>>>That's quite true, but a setter that does nothing but change is_active > >>>>doesn't prevent this. If there is logic necessary to prevent state changes > >>>>in certai
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Gerhard Fiedler wrote: > > > >>On 2006-07-15 06:55:14, mystilleef wrote: > >> > >> > >>>In very well designed systems, the state of an object should only be > >>>changed by the object. > >> > >>IMO that's not quite true. Ultimately, the state always gets changed by > >>something else (user interaction, physical events); very few objects are > >>completely self-contained in their behavior. > >> > > Then in those cases the system becomes a victim of high coupling. > > Time to burn your book and face reality. ObjA sends message Msg1 to > ObjB. Part of the associated behaviour is that in responce to Msg1, objB > changes it's own state. Practical result : ObjB's state has been changed > by ObjA. Practical question : how do you hope to avoid this "hi > coupling" (lol), apart from making all your objects totally autistic ? > Are you serious? Well, you design an object that serves as a mediator. All objects can then only interact with themselves and the mediator only. Via signals, objects learn to automatically adjust their states and respond to events. This is just one of several methods you can dramatically reduce coupling. I'm sure glad I didn't burn my book. > >>In most systems (and you possibly have written some of them) are objects > >>whose state gets changed by other objects -- possibly through the > >>intermediation of setter methods that do nothing else but set the state. > >>There's no conceptual difference between directly setting the state or > >>calling a setter function that does nothing else but directly setting the > >>state -- except for one unnecessary level of indirection in the latter. > >> > > > > > > It depends. If certain conditions need to be met before changing the > > state of an object, then arbitrarily changing it can be dangerous. > > Does this imply a 'method call' *syntax* ? That's language dependent. >Given the existence of > "computed attributes" (ie: support for 'attribute access' *syntax* with > hidden accessors) and the possibility to redefine implementation (from > default attribute r/w access to computed/controlled) without touching > the interface, why advocate the *systematic* use of computed attributes > when it's just duplicating the default behaviour ? > I'm not advocating anything. I'm just stating the use case for accessors and the wisdom behind them. My qualm with implicit accessors remains the name issue. > > > > >>>For example, a third party randomly changing is_active, (which Python > >>>lets you do freely and easily) from False to True may crash your GUI. > >>>And I'm not making this up. Things like this do really happen depending > >>>on the whackyness of your toolkit. > >> > >>That's quite true, but a setter that does nothing but change is_active > >>doesn't prevent this. If there is logic necessary to prevent state changes > >>in certain situations, this should be implemented. But whether you then > >>call this a part of the "behavior" (looking at the implementation as being > >>a setter method) or a part of the "state" (looking at the implementation as > >>being an added feature of the attribute) doesn't really make an objective > >>difference. > >> > > > > > > Of course using setters for the sake of just using them is pointless. > > Indeed. > > > The reason to use them is if pre-conditions or post-conditions need to > > be met. Or to control access to an objects states. > > Then why advocate *systematic* use of them ? > > (snip) I never advocated anything. On the contrary, I asked a query? > > > > State - behavior is not something I made up, so it isn't subjective. > > The words (and the concept they describe) are not. Interpretation of > what is state and what is behaviour is subjective. > > > It > > is a common term used in OO literature. In fact, the only reason I used > > it is because I thought is was common knowledge. > > It is. > > > And behaviors are not > > just necessarily getters/setters, they are methods of objects. > > Behaviour is how a given object reacts to a given message. *Nothing* in > this implies the notions of attributes or methods. Attributes and > methods are implementation details of the concepts of state and > behaviour, and - while this is a common implementation of OO concepts - > the choice to use non-callable attributes as representing the state > and callable ones as representing behaviour is totally > implementation-dependant. > I agree. And I already told you I think in terms of state and behavior and not language dependent semantics. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > Please don't top-post > > On State and Behavior: > > > > To understand objects in terms of state and behavior you need to > > absolve yourself from implementation details of languages > > and think at an abstract level. > > > > > Take a button object, for example. It has state and behavior. Possible > > states may include, is_active, is_focused, is_mapped, etc. Behavior is > > what the button does when it responds to events, (e.g when you click on > > it, or drag it, or position a pointer over it.) If you've done any form > > of event based programming (GUI/Games/Simulation), this method of > > thinking becomes natural. > > > > As you can see, when I'm designing a button object, I don't care what > > Python does with is_active. I don't care how it accesses. I don't care > > what is_active means to Python. I don't care about Python's __get__ > > /__set__ special/latent functions or implementation details. is_active > > to me and every other developer is a state of the button object. And at > > that level that's all that matters. Python can tell me it's just ones > > and zeros for all I care. > > > > In very well designed systems, the state of an object should only be > > changed by the object. > > ... as a response to a message. > > > For example, a third party randomly changing > > is_active, (which Python lets you do freely and easily) > > Unless you make it a read-only property. > So you see the purpose of accessors then? > > from False to > > True may crash your GUI. > > > And I'm not making this up. Things like this > > do really happen depending on the whackyness of your toolkit. So > > sometimes, it is my duty to protect the state of an object. Especially > > if its state cannot afford to be corrupted rendering the system > > unstable. And situations like this are found a plenty in event based > > programming. Which is programming objects based almost entirely on > > state and behavior. As you can see this has nothing to do with Python > > vs Java's vs X's implementation of accessors and how using them sucks, > > or how they aren't Pythonic. Some domains just require this stuff. > > Properties *are* 'accessors'. > I never said they weren't. > > One of the requirements for designing robust object systems is ensuring > > the state of objects aren't easily contaminated. > > "contaminated" ??? > Make an object's state unreliable. See above example. > > That "state" is the > > objects data (read: stuff the object needs to do something "reliably"). > > Makes no sens to me. > is_active is an object's data, with regards to our example. > > And this is why many overzealous OO languages do "force" you to use > > accessors. It's not because they hate you or aren't aware of the > > convenience of having direct access to an object's attributes. It's > > just because these languages convenience/robustness ratios are > > different. > > > > Thinking in terms of callable vs non-callable is not helpful for me, > > because it isn't high level enough. > > Allo, Huston ? > > > Thinking in terms of state and > > behavior is, because it works regardless of programming language or > > implementations. This is the reason I like working with Python. I > > wanted a language that didn't bore me with it semantics and allowed me > > to focus on design. Let me reiterate, I'm not obsessing over language > > semantics, I just need practical, not religious, solutions for my > > problem domain. > > Using properties instead of explicit getters/setters is pragmatism, not > religion. Using the default get/set mechanism when there's no specific > reason to do otherwise is pragmatism too. And understanding the object > model and idioms of the language you're using is IMHO the very pragmatic > thing to do... > Again, the object model of the language is irrelevant. The only relevant model is my application's model, which should work regardless of the language I use. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Gerhard Fiedler wrote: > On 2006-07-15 06:55:14, mystilleef wrote: > > > In very well designed systems, the state of an object should only be > > changed by the object. > > IMO that's not quite true. Ultimately, the state always gets changed by > something else (user interaction, physical events); very few objects are > completely self-contained in their behavior. > Then in those cases the system becomes a victim of high coupling. > In most systems (and you possibly have written some of them) are objects > whose state gets changed by other objects -- possibly through the > intermediation of setter methods that do nothing else but set the state. > There's no conceptual difference between directly setting the state or > calling a setter function that does nothing else but directly setting the > state -- except for one unnecessary level of indirection in the latter. > It depends. If certain conditions need to be met before changing the state of an object, then arbitrarily changing it can be dangerous. I gave an example earlier. > > For example, a third party randomly changing is_active, (which Python > > lets you do freely and easily) from False to True may crash your GUI. > > And I'm not making this up. Things like this do really happen depending > > on the whackyness of your toolkit. > > That's quite true, but a setter that does nothing but change is_active > doesn't prevent this. If there is logic necessary to prevent state changes > in certain situations, this should be implemented. But whether you then > call this a part of the "behavior" (looking at the implementation as being > a setter method) or a part of the "state" (looking at the implementation as > being an added feature of the attribute) doesn't really make an objective > difference. > Of course using setters for the sake of just using them is pointless. The reason to use them is if pre-conditions or post-conditions need to be met. Or to control access to an objects states. > > So sometimes, it is my duty to protect the state of an object. > > Of course. > > > Which is programming objects based almost entirely on state and behavior. > > As you can see this has nothing to do with Python vs Java's vs X's > > implementation of accessors and how using them sucks, or how they aren't > > Pythonic. Some domains just require this stuff. > > Yes, but you seem to still be stuck in the paradigm that setting the state > is behavior if it comes from the outside -- probably because some languages > implement that way. > Not at all. Behaviors are just methods of an object. They are behaviors whether they are called internally or externally. > I'm not (yet) a Python programmer. To be honest, the one single feature > that attracted me to Python is the structuring by indenting... I never > understood why we have to indent (to be able to read) /and/ brace (to make > the compiler happy) in other languages -- I always thought that if > indenting helps me to understand the structure, the compiler should be able > to read exactly that :) > > I come from a mostly C/C++/Java/PHP background, apparently similar to > yours. GUI, embedded, whatever. But I can understand that the difference > you are making is not based in a concept, it is based in an implementation. > > It is an artificial difference to say that > > o.is_active = true > > is modifying state, whereas > > o.set_active( true ) > > is dealing with behavior. Either way you are changing the state. Behavior, > that is, doing something, implies state change, one way or another, > sometimes relevant, sometimes not. There are (often embedded) systems, and > well-designed ones, that basically don't deal with what you call behavior > at all and handle everything through state change (of signals). Such > systems can be rock-solid and quite complex, and have a lot of "behavior". > And there are systems that do everything through what you call behavior > (e.g. getter/setter type implementations). Both types can work, both can > achieve the exactly same; this is just an implementation detail. > If all set_active does is change is_active's state, then set_active is pointless. See above for my point on the issue. > > And this is why many overzealous OO languages do "force" you to use > > accessors. > > I'm not sure why you keep on harping on this. It seems to have been clearly > stated that in Python, every attribute /is/ an implied getter/setter pair > -- it's up to you to just let the language use the default (simple) > implementation, or override it with your own logic. It is also up to you to > call this added logic then a
Re: Accessors in Python (getters and setters)
On State and Behavior: To understand objects in terms of state and behavior you need to absolve yourself from implementation details of languages and think at an abstract level. Take a button object, for example. It has state and behavior. Possible states may include, is_active, is_focused, is_mapped, etc. Behavior is what the button does when it responds to events, (e.g when you click on it, or drag it, or position a pointer over it.) If you've done any form of event based programming (GUI/Games/Simulation), this method of thinking becomes natural. As you can see, when I'm designing a button object, I don't care what Python does with is_active. I don't care how it accesses. I don't care what is_active means to Python. I don't care about Python's __get__ /__set__ special/latent functions or implementation details. is_active to me and every other developer is a state of the button object. And at that level that's all that matters. Python can tell me it's just ones and zeros for all I care. In very well designed systems, the state of an object should only be changed by the object. For example, a third party randomly changing is_active, (which Python lets you do freely and easily) from False to True may crash your GUI. And I'm not making this up. Things like this do really happen depending on the whackyness of your toolkit. So sometimes, it is my duty to protect the state of an object. Especially if its state cannot afford to be corrupted rendering the system unstable. And situations like this are found a plenty in event based programming. Which is programming objects based almost entirely on state and behavior. As you can see this has nothing to do with Python vs Java's vs X's implementation of accessors and how using them sucks, or how they aren't Pythonic. Some domains just require this stuff. One of the requirements for designing robust object systems is ensuring the state of objects aren't easily contaminated. That "state" is the objects data (read: stuff the object needs to do something "reliably"). And this is why many overzealous OO languages do "force" you to use accessors. It's not because they hate you or aren't aware of the convenience of having direct access to an object's attributes. It's just because these languages convenience/robustness ratios are different. Thinking in terms of callable vs non-callable is not helpful for me, because it isn't high level enough. Thinking in terms of state and behavior is, because it works regardless of programming language or implementations. This is the reason I like working with Python. I wanted a language that didn't bore me with it semantics and allowed me to focus on design. Let me reiterate, I'm not obsessing over language semantics, I just need practical, not religious, solutions for my problem domain. Bruno Desthuilliers wrote: > mystilleef wrote: > (snip) > > > > Okay, I feel I need to make myself clear. I certainly I'm not blaming > > Python for my mistakes. And I don't think language X is better than > > Python or vice-versa. Okay scrap the vice-versa. It was silly of me to > > name the variable tmp regardless of whatever excuses I have. This also > > doesn't mean in the future I wouldn't use shitty names for my > > attributes. :-) I most likely will. But at least now I know how to > > minimize its impact of such carelessness. I mentioned them above but I > > repeat it hear again. > > > > 1). Make all attributes of a class private/protected . > > Please re-read my answer to your previous mention of this and my other > remarks in this thread (and below in this thread) about the profound > differences between Python and Java wrt/ object model and attribute > access semantics. > > > 2). If a "non-callable" attribute is going to be used outside a class, > > think about making it a property > > Unless you don't need to. > > > and name the property well, > > Indeed !-) > > > Other than that we are just arguing semantics of language. For example, > > your view of objects is by categorizing its attributes in callable and > > non-callable. > > And also API/implementation. These are to orthogonal problems - even in > Java FWIW !-) > > > However, my categorization is state(data) and > > behavior(methods). > > If properties are an equivalent of getters/setters, are properties state > or behaviour ? According to your views, they are behaviour, if I > understood you. In that case, what's the difference between 'directely' > (which in fact implies going thru __getattribute__) accessing a public > "data" attribute and accessing an implementation attribute by the mean > of a desc
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Bruno Desthuilliers wrote: > > > >>mystilleef wrote: > >> > (snip) > >>>> > >>>>>I have used that name in > >>>>>dozens of places spanning over 27000 LOC. > >>>> > >>>>Too bad for you. > >>> > >>> > >>>Thank you, that was helpful. > >> > >>What am I supposed to say ? You choose a bad name for a public symbol, > >>used it in 27000 lines of Python code (which certainly took some time to > >>write), > > > > > > This is a __baseless__ statement. > > Please explain what's wrong ? The "bad naming" part is your own > statement, the "27000 lines" is your own statement too, and I don't see > what's wrong with the assumption that producing 27000 lines of Python > took some time. > > > For all you know I could have used > > the attribute twice in those 27000 lines of code. > > How does this make my statement wrong ? Did I imply that you used this > attribute in each and any of the 27000 lines ? > > > Even then searching > > for and replacing the attribute is tedious and error prone. > > Indeed, and whether you believe it or not, I do share your pain here. I > had to face similar problem, and without even find and grep (a dumb > 'CASE Tool' that stored it's proprietary language code in a > non-documented binary format and was missing decent, reliable > search/replace utilities). And the project was actually more than > 50KLOC, forms description excluded. > > > > >>and all of a sudden you realize the name is bad and proceed to > >>fix the problem. > > > > Yes, the same way many programmers suddenly realize their class, > > function, method, project, etc is poorly designed even after using it > > for months and proceed to fix the problem. Shit happens. > > Agreed. I don't pretend to be better than anyone else at this. > > > > >>If you know of any other way than a massive > >>find/replace, please share. > > > > > > I wouldn't have started the topic if I did. Apparently the only > > solution is to rereference the attribute with a better name and pray > > and hope third party developers will use the better name. Or search and > > replace! > > Is actually this code already published ? If yes, you have the option of > making the 'tmp' accessor a computed attribute pointing to the better > named one, have the hidden getter/setter code emit a warning (including > useful informations about where the attributes is accessed - this is > opened to inspection), and officialy deprecate the badly named attribute > so you can definitively get rid of it in a near release. > > > > >>But blaming the language for your error won't help. > > > > I did no such thing, you are making that up. > > Sorry, that's what I understood. If it's me being guilty of > overreaction, please accept my apologies. > > > > >>>>>There's a chance that other > >>>>>develops might misinterpret exactly what "tmp" does. Plus I don't want > >>>>>emails from other developers querying me about what "tmp" is/does. > >>>>>"tmp" is obvious to me, but not necessarily to others. > >>>> > >>>>So why did you name it that way at first ? > >>>> > >>> > >>>What does it matter? There are 10 million and one reasons from given > >>>identifiers bad names. > >> > >>And how many reasons to use a bad name in 27000 LOCs before deciding to > >>fix the problem ? > >> > > > > Do you really think I used the name 27000 times in 27000 lines of code? > > Of course not. But since 27KLOC is far from trivial for a Python > application, one can think that you had time to notice something wrong > with the naming/use of this attribute. > > > Maybe I'm not making myself clear. Having to search 27000 lines of code > > to replace an identifier name is tedious and error prone. > > Yes. You can of course encapsulate access to the attribute in a property > and have that property either emit a warning, raise an exception, log > the access etc, so if you missed some use of it, chances are you'll find > out pretty soon. Unit tests may help too - they can be great for > reporting broken code. You may also want to look if lint-like tools > (pylint etc) can help you there. > > > > >>>>>Now c
Re: Accessors in Python (getters and setters)
Ant wrote: > We seem to be flogging a dead horse now. Is the following a fair > summary: > > Q. What is the Pythonic way of implementing getters and setters? > > A. Use attributes. > > Quote: "I put a lot more effort into choosing method and function > names" > > Wisdom: Python is a different paradigm from (e.g.) Java w.r.t. > accessors: Put the effort you would have put into choosing accessor > names into choosing attribute names. > > Anything else to add to this? Or can it be put to bed? Here are the lessons I've learned (the hard way). 1) Make all attributes of a class private or protected. You can make them public later if need be. If anyone tells you making attributes private/protected is not Pythonic ignore them. You'll thank me when your code base grows. 2) If a data attribute might likely be an API, think about controlling access to via "properties". That's the pythonic way to implement accessors and mutators I guess people who've done medium to large scale programming in Python already know this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Bruno Desthuilliers wrote: > > > >>mystilleef wrote: > >>(snip) > >> > >>>Python doesn't have any philosophy with regards to naming identifiers. > >> > >>Yes it does. > > > > > > No it doesn't. > > > > > >>>>But they are in Python and that is the python's philosophy. All attribute > >>>>or > >>>>method not beginning with an '_' *is* API. > >>> > >>>Right, and what if I want to change a private API to a public one. > >> > >>Then you provide a public API on top of the private one. > >> > >>class MyClass(object): > >> def __init__(self, ...): > >> self._attr = XXX > >> > >> # seems like we really have enough use > >> # cases to justify exposing _imp_attr > >> @apply > >> def attr(): > >>def fget(self): > >> return self._attr > >>def fset(self): > >> self._attr = attr > >>return property(**locals()) > >> > >> > >> def _method(self, ...): > >># code here > >> > >> # seems like we really have enough use > >> # cases to justify exposing _imp_method > >> method = _impmethod > >> > >>Note that none of this actually breaks encapsulation. > > > > > > Ha! Just as bad as getters and setter. > > What point are you trying to make here ? Of course a computed attribute > is just syntactic sugar for getters and setters - what else could it be? > > The difference is that you don't need to write explicit getters/setters > beforehand, nor to use a "behaviour" semantic. > > > > >>>How > >>>does that solve my naming issues. > >> > >>How could this solve *your* naming issue ? This is totally unrelated. > >>You choose a bad name for a *public* symbol. > > > > > > My point exactly! It doesn't solve my problem! > > What do you hope ? Something that cures cancer ? Please enlighten us and > explain how explicit getters/setters would have solved the problem of > badly named getters/setters ? > I did already. If I had used Java, Eiffel, Smalltalk or C++, I would have easily changed tmp to temporary_buffer without having search and replace or grep 27000 lines of code. The point of accessors in those languages is encapsulation. Which means I can change any detail of implementation, yes including names of attributes, without breaking code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Bruno Desthuilliers wrote: > > > >>mystilleef wrote: > >> > >>>Lousy Attribute Name: > >>> self.tmp > >>> > >>>Accessors: > >>> set_temporary_buffer > >>> get_temporary_buffer > >>> > >>>The attribute name I chose, "tmp" sucks. > >> > >>Well, it's surely not as descriptive as 'temporary_buffer' > >> > >> > >>>I have used that name in > >>>dozens of places spanning over 27000 LOC. > >> > >>Too bad for you. > > > > > > Thank you, that was helpful. > > What am I supposed to say ? You choose a bad name for a public symbol, > used it in 27000 lines of Python code (which certainly took some time to > write), This is a __baseless__ statement. For all you know I could have used the attribute twice in those 27000 lines of code. Even then searching for and replacing the attribute is tedious and error prone. >and all of a sudden you realize the name is bad and proceed to > fix the problem. Yes, the same way many programmers suddenly realize their class, function, method, project, etc is poorly designed even after using it for months and proceed to fix the problem. Shit happens. >If you know of any other way than a massive > find/replace, please share. I wouldn't have started the topic if I did. Apparently the only solution is to rereference the attribute with a better name and pray and hope third party developers will use the better name. Or search and replace! >But blaming the language for your error won't help. I did no such thing, you are making that up. > > > > >>>There's a chance that other > >>>develops might misinterpret exactly what "tmp" does. Plus I don't want > >>>emails from other developers querying me about what "tmp" is/does. > >>>"tmp" is obvious to me, but not necessarily to others. > >> > >>So why did you name it that way at first ? > >> > > What does it matter? There are 10 million and one reasons from given > > identifiers bad names. > > And how many reasons to use a bad name in 27000 LOCs before deciding to > fix the problem ? > Do you really think I used the name 27000 times in 27000 lines of code? Maybe I'm not making myself clear. Having to search 27000 lines of code to replace an identifier name is tedious and error prone. > >>>Now compare that > >>>to the accessors. > >> > >>But 'tmp' actually *is* an accessor. > > > > > > I didn't say it wasn't. > > Yes you did. May I quote ? > """ > "tmp" is obvious to me, but not necessarily to others. Now compare that > to the accessors. Not only do they improve readability at the expense > of more code, they actually allow me to change the lousily named > attribute "tmp" to "temporary_buffer" without grepping, seding, > searching, replacing and praying. > """ > > This obviously implies that you don't understand 'tmp' as being an accessor. > You are quoting me out of context. I was speaking with respect to real accessors, not Python's latent implementation mechanisms. > >>>Not only do they improve readability > >> > >>Err... do you find: > >> > >>obj.set_temporary_buffer(val) > >>val = obj.get_temporary_buffer() > >> > >>really more readable than: > >> > >>obj.temporary_buffer = val > >>val = obj.temporary_buffer > > > > > > I didn't name the attribute temporary_buffer, I named it tmp. > > You didn't name the *accessor* 'temporary_buffer', you named it 'tmp'. > You are *exactly* in the same situation as if you had used getter/setter > named "get_tmp" and 'set_tmp". And your point about getters/setters > "improving readability" is moot. > No I'm not. Naming attributes and naming methods are entirely different situations. > > > >>>at the expense > >>>of more code, > >> > >>Indeed. In both the class and client code. > >> > >> > >>>they actually allow me to change the lousily named > >>>attribute "tmp" to "temporary_buffer" without grepping, seding, > >>>searching, replacing and praying. > >> > >>You still fail to get the point. You actually choose a crappy name for a > >>*public* property. It's *exactly* a
Re: Accessors in Python (getters and setters)
Fredrik Lundh wrote: > "mystilleef" wrote: > > > Pretending to be intelligent does, however. > > so the real reason you've written a few hundred posts saying basically "I pick > bad names, which proves... uh... whatever" is to impress people by pretending > to be something you're not ? > > Choosing bad identifiers is not a measure of intelligence. Given your standing in the Python community, I expect more from you. If your only contribution to this thread is snide and derisive remarks, you leave me no choice but to ignore you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Fredrik Lundh wrote: > "mystilleef" wrote: > > >> if your code is as muddled as your rhetorics, your only solution might be > >> to give up programming. > > > > There's no correlation between rhetorics and programming. That's like > > me saying if you are trying to be sarcastic your only solution might be > > to give up programming. > > sarcasm doesn't imply lack of intelligence. > > Pretending to be intelligent does, however. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Marc 'BlackJack' Rintsch wrote: > > > >>In <[EMAIL PROTECTED]>, mystilleef > >>wrote: > >> > >> > >>>Maric Michaud wrote: > (snip) > > >>>>But they are in Python and that is the python's philosophy. All attribute > >>>>or > >>>>method not beginning with an '_' *is* API. > >>> > >>>Right, and what if I want to change a private API to a public one. How > >>>does that solve my naming issues. > >> > >>Then you have to change all references to that private attribute. What's > >>the problem here? As it was private I would expect to find all the > >>references "nearby" in the same module or class. > > > > Right, but tmp isn't private. > > Right, but that's your choice. Would you complain about "almost any > other language" if you had to hunt a badly named public method thru 27KLOC ? > Methods are used to perform actions. Data attributes usually aren't. We are on different planes. > (snip) > > >>Python is not almost all other languages and in Python code you usually > >>won't find those trivial getters and setters because we have properties if > >>the access might become a bit more complex in the future. > >> > > Ha! I bet you haven't read too many Python codes. > > > I have read tens of thousands LOC of Python in the seven past years. > Computed attributes came in with 2.2x IIRC, so there's a lot of 'legacy' > code that uses getters and setters. Porting this code to a > computed-attribute style would break all client code. Having the two > schemes coexisting would make for bloated APIs and > too-many-ways-to-do-it. So we live with this until Py3K. And none of > these considerations contradicts the point that there's no more use for > javaish getters/setters in Python, nor that javaish getters/setters are > not pythonic. > I never made any contradictory points regarding the matter. I wanted to know the pythonic way of using accessors in Python. That's all. You are the person making wild assumptions about my queries, programming background and code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Fredrik Lundh wrote: > "mystilleef" wrote: > > > Right, and what if I want to change a private API to a public one. How > > does that solve my naming issues. > > if your code is as muddled as your rhetorics, your only solution might be > to give up programming. > > There's no correlation between rhetorics and programming. That's like me saying if you are trying to be sarcastic your only solution might be to give up programming. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > (snip) > > Python doesn't have any philosophy with regards to naming identifiers. > > Yes it does. No it doesn't. > > > >>But they are in Python and that is the python's philosophy. All attribute or > >>method not beginning with an '_' *is* API. > > > > Right, and what if I want to change a private API to a public one. > > Then you provide a public API on top of the private one. > > class MyClass(object): > def __init__(self, ...): > self._attr = XXX > > # seems like we really have enough use > # cases to justify exposing _imp_attr > @apply > def attr(): > def fget(self): > return self._attr > def fset(self): > self._attr = attr > return property(**locals()) > > > def _method(self, ...): > # code here > > # seems like we really have enough use > # cases to justify exposing _imp_method > method = _impmethod > > Note that none of this actually breaks encapsulation. Ha! Just as bad as getters and setter. > > How > > does that solve my naming issues. > > How could this solve *your* naming issue ? This is totally unrelated. > You choose a bad name for a *public* symbol. My point exactly! It doesn't solve my problem! > >>And in python the reverse can be true : > > > > The reverse is hardly ever true. > > So what are computed attributes ? > > > 90% of public APIs in almost all > > languages are methods or functions. > > "allmost all languages" lacks computed attributes. > *sighs* -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Marc 'BlackJack' Rintsch wrote: > In <[EMAIL PROTECTED]>, mystilleef > wrote: > > > Maric Michaud wrote: > >> But that's not python philosophy. > > Python doesn't have any philosophy with regards to naming identifiers. > > But the python community has one. Pythonistas prefer readable source code > so they tend to think about good names. As The Zen of Python says > "Readability counts." I'm glad I'm in tune with the "python community." > > >> But they are in Python and that is the python's philosophy. All attribute > >> or > >> method not beginning with an '_' *is* API. > > Right, and what if I want to change a private API to a public one. How > > does that solve my naming issues. > > Then you have to change all references to that private attribute. What's > the problem here? As it was private I would expect to find all the > references "nearby" in the same module or class. Right, but tmp isn't private. > >> And in python the reverse can be true : > > The reverse is hardly ever true. 90% of public APIs in almost all > > languages are methods or functions. > > Except the ones with properties where ordinary "attributes" may be just > calls in disguise. Crap! Even in Python too most Public APIs are methods and functions. > Python is not almost all other languages and in Python code you usually > won't find those trivial getters and setters because we have properties if > the access might become a bit more complex in the future. > Ha! I bet you haven't read too many Python codes. > Ciao, > Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Bruno Desthuilliers wrote: > mystilleef wrote: > > Lousy Attribute Name: > > self.tmp > > > > Accessors: > > set_temporary_buffer > > get_temporary_buffer > > > > The attribute name I chose, "tmp" sucks. > > Well, it's surely not as descriptive as 'temporary_buffer' > > > I have used that name in > > dozens of places spanning over 27000 LOC. > > Too bad for you. Thank you, that was helpful. > > > There's a chance that other > > develops might misinterpret exactly what "tmp" does. Plus I don't want > > emails from other developers querying me about what "tmp" is/does. > > "tmp" is obvious to me, but not necessarily to others. > > So why did you name it that way at first ? > What does it matter? There are 10 million and one reasons from given identifiers bad names. > > Now compare that > > to the accessors. > > But 'tmp' actually *is* an accessor. I didn't say it wasn't. > > > Not only do they improve readability > > Err... do you find: > > obj.set_temporary_buffer(val) > val = obj.get_temporary_buffer() > > really more readable than: > > obj.temporary_buffer = val > val = obj.temporary_buffer I didn't name the attribute temporary_buffer, I named it tmp. > > > at the expense > > of more code, > > Indeed. In both the class and client code. > > > they actually allow me to change the lousily named > > attribute "tmp" to "temporary_buffer" without grepping, seding, > > searching, replacing and praying. > > You still fail to get the point. You actually choose a crappy name for a > *public* property. It's *exactly* as if, in Java, you had named your > getter/setter 'get_tmp' and 'set_tmp'. > No, it isn't. In Java there's a clear distinction between attributes and methods. > > Sure, if you are dealing with less > > than a 1000LOC you can get away with using "tmp" or renaming it easily. > > But if you are dealing with a much larger code base and more > > developers, issues like this rapidly become a nuisance. > > Indeed. But it's *your* responsability to choose good names for the API. > I choose good names for most of my APIs. But there cases when you never know an attribute will actually be an API before hand. > > Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp). > or 'tmp'. > > > But developers tend to pay more attention to given methods/functions > > less crappy names, at least when compared to data attributes. > > s/developpers/you/ > Ha, right! I bet you are perfect developer. > > This > > stems from the fact that in many languages data attributes aren't > > usually part of the API, > > Once again, in Python, there is *no* such thing as 'data attributes'. > *All* attributes are *objects* - some of them callable. > I didn't say attributes weren't objects. > > as well as the whole OO(Encapsulation) blah > > blah. > > Don't confuse encapsulation with data-hiding. I don't see the confusion. > > > I know I would not name the accessors set_tmp/get_tmp, because my > > philosophy is that methods/functions need to have meaningful names and > > state their intended purpose. > > That's true for each and every name in a program. > > > I don't hold data attributes to such > > standards > > Too bad for you. > Thank you. > > and I imagine many developers don't either and least based on > > other people's code I've read. Plus there are many occassions when > > attributes are not intended to be APIs, > > Then mark them as being implementation (ie : prefix them with a single > underscore). I thought that too was unpythonic. > > but eventually become one. > > After all most data attributes are created with the purpose of serving > > methods. > > Nope. You have the class API, and the class implementation. Both made of > both callable and non-callable attributes. > Or objects have state and behavior. Data attributes represent state and methods represent behavior. > Mystilleef, I do share your pain (really - been here, done that, > etc...), and I understand that grasping Python requires some mental > adjustments when coming from Java and friends (been here, done that, > etc...). But you seriously can't blame the language for your own mistakes. > You don't share my pain. You seem to mock it. I'm not new to Python either. I've been using it for over 2 years in several capac
Re: Accessors in Python (getters and setters)
Maric Michaud wrote: > Not python developers. Nonsense! > But that's not python philosophy. Python doesn't have any philosophy with regards to naming identifiers. > But they are in Python and that is the python's philosophy. All attribute or > method not beginning with an '_' *is* API. Right, and what if I want to change a private API to a public one. How does that solve my naming issues. > And in python the reverse can be true : The reverse is hardly ever true. 90% of public APIs in almost all languages are methods or functions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Lousy Attribute Name:
self.tmp
Accessors:
set_temporary_buffer
get_temporary_buffer
The attribute name I chose, "tmp" sucks. I have used that name in
dozens of places spanning over 27000 LOC. There's a chance that other
develops might misinterpret exactly what "tmp" does. Plus I don't want
emails from other developers querying me about what "tmp" is/does.
"tmp" is obvious to me, but not necessarily to others. Now compare that
to the accessors. Not only do they improve readability at the expense
of more code, they actually allow me to change the lousily named
attribute "tmp" to "temporary_buffer" without grepping, seding,
searching, replacing and praying. Sure, if you are dealing with less
than a 1000LOC you can get away with using "tmp" or renaming it easily.
But if you are dealing with a much larger code base and more
developers, issues like this rapidly become a nuisance.
Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
But developers tend to pay more attention to given methods/functions
less crappy names, at least when compared to data attributes. This
stems from the fact that in many languages data attributes aren't
usually part of the API, as well as the whole OO(Encapsulation) blah
blah. I know I would not name the accessors set_tmp/get_tmp, because my
philosophy is that methods/functions need to have meaningful names and
state their intended purpose. I don't hold data attributes to such
standards and I imagine many developers don't either and least based on
other people's code I've read. Plus there are many occassions when
attributes are not intended to be APIs, but eventually become one.
After all most data attributes are created with the purpose of serving
methods.
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Hello,
> >
> > Thanks for the responses. The reason I want to change the name of the
> > attribute is because it doesn't reflect the purpose of the attribute,
> > anymore. The attribute was originally a string object, but not anymore.
> > It is primarily a readability issue. There are also a few key
> > attributes I don't want developers, including myself, fiddling with.
> > Properties /accessors are good because they allow you to encapsulate
> > attributes so you can change implementations at will. Some of you have
> > argued I would have needed to change accessor names too if I had
> > misnamed them earlier. It's hard to say. I find myself changing the
> > names of attributes a lot more frequently than I do functions or
> > methods. Choosing a crappy attribute name is effortless for me,
> > especially during intense coding sessions. I usually realize I've
> > choosing a crappy attribute name the next day, sometimes even later.
> > However, I put a lot more effort into choosing method and function
> > names, especially when I know it may likely be a public API.
>
> What you need to understand here is that in Python,
> 1/ methods *are* attributes
> 2/ every attribute whose name is not prefixed by a leading underscore is
> considered part of the api ('__magic__' names being a special case).
>
> So it has nothing to do with "data vs method" dichotomy (which makes no
> sens in a languages where functions and methods are objects), only with
> "API vs implementation". You choosed a crappy name for an attribute
> that's part of the API, so it's *exactly* the same case as if you had
> chosen a crappy name for a public method in Java. Think of public "data"
> attributes as magical getter/setters with the most straightforward
> behaviour, and of properties as the way to override this default behaviour.
>
> > Plus it's
> > really hard to choose crappy accessor name.
>
> What about getMyCrappyAttributeName/setMyCrappyAttributeName ?-)
>
>
>
> --
> bruno desthuilliers
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
Hello, Thanks for the responses. The reason I want to change the name of the attribute is because it doesn't reflect the purpose of the attribute, anymore. The attribute was originally a string object, but not anymore. It is primarily a readability issue. There are also a few key attributes I don't want developers, including myself, fiddling with. Properties /accessors are good because they allow you to encapsulate attributes so you can change implementations at will. Some of you have argued I would have needed to change accessor names too if I had misnamed them earlier. It's hard to say. I find myself changing the names of attributes a lot more frequently than I do functions or methods. Choosing a crappy attribute name is effortless for me, especially during intense coding sessions. I usually realize I've choosing a crappy attribute name the next day, sometimes even later. However, I put a lot more effort into choosing method and function names, especially when I know it may likely be a public API. Plus it's really hard to choose crappy accessor name. Regards -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessors in Python (getters and setters)
I decided to change the name of an attribute. Problem is I've used the attribute in several places spanning thousands of lines of code. If I had encapsulated the attribute via an accessor, I wouldn't need to do an unreliable and tedious search and replace accross several source code files to achieve my goal. I could simply change the name of the attribute and move on. Well, I'm glad python has properties. It's a feature that should be advertised more, especially for large scale python development. Diez B. Roggisch wrote: > mystilleef wrote: > > > Hello, > > > > What is the Pythonic way of implementing getters and setters. I've > > heard > > people say the use of accessors is not Pythonic. But why? And what is > > the alternative? I refrain from using them because they smell > > "Javaish." > > But now my code base is expanding and I'm beginning to appreciate the > > wisdom behind them. I welcome example code and illustrations. > > Which wisdom do you mean? The wisdom that a language that has no property > mechanism and thus can't intercept setting and getting of instance members > needs a bulky convention called JAVA Beans, so that _all_ uses of > properties are tunneled through some code, even if only a few percent of > these actually need that? > > Or the wisdom that strangling developers by putting access modifiers with > approx. a dozen different rules in place is an annoyance to adult > developers to say the least? > > These are the reasons they are not pythonic. We can intercept property > access (see the property descriptor, http://pyref.infogami.com/property), > and we trust in developers being able to judge form themselves if messing > with internals of code is a good idea or not. > > Regards, > > Diez -- http://mail.python.org/mailman/listinfo/python-list
Accessors in Python (getters and setters)
Hello, What is the Pythonic way of implementing getters and setters. I've heard people say the use of accessors is not Pythonic. But why? And what is the alternative? I refrain from using them because they smell "Javaish." But now my code base is expanding and I'm beginning to appreciate the wisdom behind them. I welcome example code and illustrations. Regards -- http://mail.python.org/mailman/listinfo/python-list
Re: a good programming text editor (not IDE)
On linux, I recommend Scribes. It's simple, slim and sleek, yet powerful. Features: Automatic completion Automatic bracket completion and smart insertion Snippets (ala TextMate) Bookmarks Syntax highlight for more than 30 languages Launches faster than any IDE out their Has no learning curve. Features your typical text processing operations you'll find in VIM/Emacs. Remembers window position and size. Sexy interface that actually adheres to human interface guidlines And many more... The next version will even feature remote editing. website: ( http://scribes.sourceforge.net/ ) Flash Demo: ( http://scribes.sourceforge.net/snippets.htm ) GIF Demo: ( http://www.minds.may.ie/~dez/images/blog/scribes.html ) John Salerno wrote: > I know there's a request for a good IDE at least once a week on the ng, > but hopefully this question is a little different. I'm looking for > suggestions for a good cross-platform text editor (which the features > for coding, such as syntax highlighting, etc.) but not a full IDE with > all the fancy jazz (GUI developer, UML diagrams, etc.). > > Ideally, it would be something I could even put on a flash drive and > move from computer to computer, but this isn't necessary. Just something > I can immediately use in either Windows or Linux (or Mac, if necessary). > > Based on another thread, I tried out Scite, but no matter what I do it > doesn't seem to remember the window size and position, or any options I > choose (like showing line numbers). It seems to always reset itself each > time I open it. > > And naturally there are Emacs and Vim, but I just don't know if I need > to invest *that* much time into learning one of them (probably Vim, > since I hear it's lighter and faster). > > I've tried a few others, like TextPad and Crimson, and right now I use > UltraEdit, which I love actually, except for minor issues here and > there. But it'd be nice to make the move, as much as possible, to free, > open-source, cross-platform software. > > Thanks for any suggestions, and again I'm sorry if this feels like the > same question as usual (it's just that in my case, I'm not looking for > something like SPE, Komodo, Eric3, etc. right now). -- http://mail.python.org/mailman/listinfo/python-list
Re: what are you using python language for?
Desktop application development -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Python Editor
http://scribes.sourceforge.net/
http://scribes.sourceforge.net/snippets.htm (Flash Demo)
Manoj Kumar P wrote:
> Hi,
>
> Can anyone tell me a good python editor/IDE?
> It would be great if you can provide the download link also.
>
> Thank You,
> -Manoj-
>
>
> "SASKEN RATED Among THE Top 3 BEST COMPANIES TO WORK FOR IN INDIA - SURVEY
> 2005 conducted by the BUSINESS TODAY - Mercer - TNS India"
>
>SASKEN BUSINESS DISCLAIMER
> This message may contain confidential, proprietary or legally Privileged
> information. In case you are not the original intended Recipient of the
> message, you must not, directly or indirectly, use, Disclose, distribute,
> print, or copy any part of this message and you are requested to delete it
> and inform the sender. Any views expressed in this message are those of the
> individual sender unless otherwise stated. Nothing contained in this message
> shall be construed as an offer or acceptance of any offer by Sasken
> Communication Technologies Limited ("Sasken") unless sent with that express
> intent and with due authority of Sasken. Sasken has taken enough precautions
> to prevent the spread of viruses. However the company accepts no liability
> for any damage caused by any virus transmitted by this email
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
I agree, use tabs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python editor recommendation.
The powerful no-nonsense, no-frills, no-hassle, no-fuzz editor, Scribes. Supports everything you'd want in an editor, it's nimble, fast and agile, and it has virtually no learning curve. http://scribes.sourceforge.net/ http://scribes.sourceforge.net/snippets.htm (Flash Demo) http://www.minds.nuim.ie/~dez/images/blog/scribes.html (GIF Demo) -- http://mail.python.org/mailman/listinfo/python-list
Re: Designing Plug-in Systems in Python
Thanks for the pointers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best IDE for Python?
What OS? IDEs are overkill, bloated, complex and slow for agile languages like Python. You need an editor that is nimble, fast, simple, powerful and doesn't get in your way. For linux, I suggest Scribes. http://scribes.sf.net http://scribes.sf.net/snippets.htm (Flash Demo) http://www.minds.nuim.ie/~dez/images/blog/scribes.html (GIF Demo) -- http://mail.python.org/mailman/listinfo/python-list
Designing Plug-in Systems in Python
Hello, I need to design a plug-in system for a project. The goal is to allow third party developers interact with an application via plug-ins in a clean and robust manner. At this point I am overwhelmed by my inexperience with designing plug-in systems. Are there any good tutorials on how to design good plug-in systems with Python, or any language? What are the best practices for designing plug-in systems in Python? How would you go about designing one? What are common pitfalls in designing one? Any pointers, suggestions, resources and advice is welcome. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
I agree. Lists should have a clear method. But what's shocking is that it doesn't seem obvious to others. list.clear() is a whole lot more readable, intuitive, "flowable" and desirable than del list. Or maybe I haven't had enough coffee this morning. I'd go as far as saying all container objects should have a clear method. This is the reason why those Rubyist whine about Python being inconsistent and not being "OO enough." -- http://mail.python.org/mailman/listinfo/python-list
Re: Best IDE for Python?
Good luck finding the best Python IDE. :-) While you are at it, have a look at Scribes. It's great for Python editing and it's even written in Python. If you appreciate KISS, I'm positive you'd appreciate Scribes. And if you yearn for an editor that doesn't get in your way, or that allows you to focus exclusively on coding, then it is for you. http://scribes.sf.net/ GIF Demo: http://www.minds.may.ie/~dez/images/blog/scribes.html Flash Demo: http://scribes.sf.net/snippets.htm -- http://mail.python.org/mailman/listinfo/python-list
Re: What's The Best Editor for python
Scribes http://scribes.sf.net/ Flash Demo: http://scribes.sf.net/snippets.htm GIF Demo: http://www.minds.may.ie/~dez/images/blog/scribes.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Why I chose Python over Ruby
Simple, clarity! Ruby reads like Perl's younger cousin. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do you move to a new line in your text editor?
On Linux you can try out Scribes. It has a function to convert tabs to spaces. Personally, I use tabs in all my projects. http://scribes.sf.net/snippets.htm http://scribes.sf.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: editor for Python on Linux
I'm writing a simple yet powerful text editor for GNOME that is great for Python development called Scribes. It features Snippets (ala Textmate/Eclipse) Automatic word completion Automatic indentation Automatic bracket completion Automatic saving Bookmarks Syntax Highlight etc.. Flash Movie: http://scribes.sf.net/snippets.htm Gif Screencast: http://www.minds.may.ie/~dez/images/blog/scribes.html Hompage: http://scribes.sf.net/ It's faster, lighter, simpler and as powerful than the alternatives, and most important it never gets in your way and you would never need to decipher cryptic manuals to do anything moderately productive, unlike some other editors. It's free software too, give it a try. As a bonus, it's written in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Overlapping Regular Expression Matches With findall()
Hello, Thanks for your response. I was going by the definition in the manual. I believe a search only returns the first match of a regular expression pattern in a string and then stops further searches if one is found. That's not what I want. I want a pattern that scans the entire string but avoids returning duplicate matches. For example "cat", "cate", "cater" may all well be valid matches, but I don't want duplicate matches of any of them. I know I can filter the list containing found matches myself, but that is somewhat expensive for a list containing thousands of matches. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Overlapping Regular Expression Matches With findall()
Hello, Is there a simple flag to set to allow overlapping matches for the findall() regular expression method? In other words, if a string contains five occurrences of the string pattern "cat", calling findall on the string returns a list containing five "cat" strings. Is it possible for findall() to just return one "cat" string? Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Let My Terminal Go
Hello, Thanks to all the responders and helpers on the group. I'm learning everyday. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Let My Terminal Go
Hello, Thank you. That's all I needed. For some reason, I had always assumed forking was an expensive process. I guess I was ill-informed. -- http://mail.python.org/mailman/listinfo/python-list
