Re: Inquiry regarding the name of subprocess.Popen class
On Sep 1, 9:23 am, Jeremy Banks <[EMAIL PROTECTED]> wrote: > Hi. I wondered if anyone knew the rationale behind the naming of the > Popen class in the subprocess module. Popen sounds like the a suitable > name for a function that created a subprocess, but the object itself is > a subprocess, not a "popen". It seems that it would be more accurate to > just name the class Subprocess, can anyone explain why this is not the > case? The Python class is a generalization of the standard Posix function of (almost) the same name: http://opengroup.org/onlinepubs/007908775/xsh/popen.html Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: GUI Programming by hand not code with Python Code
On Jul 8, 10:09 pm, sturlamolden <[EMAIL PROTECTED]> wrote: [...] > I use wxFormBuilder with wxPython. Works like a charm. Design the GUI > graphically, export it like a wx XML resource (.xrc). All you nedd to > code in Python is the event handlers and the code to bind/hook the > events. > > http://sturlamolden.blogspot.com/2008/03/howto-using-wxformbuilder-wi... I also use wxFormBuilder, but I use XRCed from wxPython 2.8.6.x to generate an application Skeleton from my .xrc file. This version creates explicit attributes for all the visual elements that have a name in the xrc file. Unfortunately the latest XRCed version requires you to annotate the xrc in order to obtain the same effect which is not only tedious, but as far as I can tell it also makes it impossible to round trip between XRCed and wxFormBuilder. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Help need with subprocess communicate
On Jun 4, 9:56 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On Tue, 3 Jun 2008 23:48:38 -0700 (PDT), [EMAIL PROTECTED] declaimed the > following in comp.lang.python: > > > Is there way to configure the stdout buffer size so that it flushes > > earlier.. > > Is there a way to make above mentioned piece code working? > > I believe there is a command line argument that will set Python into > an unbuffered mode... BUT, unless the spawned process/program has some > similar option, you have no control over its output. Which is why the Cookbook recipe I pointed to in my other message appears to be a superior alternative. Its author works around this problem by subclassing Popen to use non blocking I/O. I used it to drive ClearCase's cleartool interactive tool and it works very well. The only problem I encountered is that it doesn't mix well with framework that have their own event loop (wxPython in my case), but you can't really expect that to work. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Help need with subprocess communicate
On Jun 3, 11:04 pm, [EMAIL PROTECTED] wrote:
> I'm trying to perform following type of operation from inside a python
> script.
> 1. Open an application shell (basically a tcl )
> 2. Run some commands on that shell and get outputs from each command
> 3. Close the shell
[...]
> Following is my code:
>
> from subprocess import *
> p2 = Popen('qdl_tcl',stdin=PIPE,stdout=PIPE)
> o,e = p2.communicate(input='qdl_help \n qdl_read \n
> qdl_reg_group_list ')
>
> Please suggest a way to perform it interactively with killing the
> process each time I want to communicate with it.
Here's what you need:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554
Cheers,
Nicola Musatti
--
http://mail.python.org/mailman/listinfo/python-list
Re: Code correctness, and testing strategies
On Jun 3, 12:35 am, [EMAIL PROTECTED] (Jacob Hallen) wrote: > In article <[EMAIL PROTECTED]>, > > David <[EMAIL PROTECTED]> wrote: [...] > >That's why you have human testing & QA. Unit tests can help, but they > >are a poor substitute. If the customer is happy with the first > >version, you can improve it, fix bugs, and add more unit tests later. > > The most important aspect of usnit testing is actually that it makes the code > testable. > This may sound lik an oxymoron but it is actually a really important > property. Testable > code has to have a level of modularity as well as simplicity and clarity in > its > interfaces that you will not achieve in code that lacks automated unit tests. I don't agree. To me the most important aspect of unit testing is that it is automated. That is, the time you spend writing new tests you reap each time you run your test suite. The fact that writing automated tests has a beneficial effect on the modularity of your code is a pleasant though hard to measure side effect. Automation should also be the most convincing argument for the OP. The most evident liability of the approach he described is the need to re- instrument his code all over again each time. Writing an equivalent set of automated tests is likely to take him more, but the time taken to write each test is time he doesn't need to spend anymore. [...] > Another aspect that you are raising is the use of human testing and QA. I > agree that > these are important, but every bug they discover is a failure of the > developers and > their tests. Our testers can sail through a testbed in 30 minutes if there > are no bugs. > Every single bug adds 30-60 minutes of testers time in order to pinpoint the > bug > and supply the developers with enough information to locate and fix it. Add > some > 10 minutes to testing time on the next testbed to verify that the bug is > actually > fixed. In my end of the world, tester time is not cheaper than developer > time. It > is also a scarcer resource than developer time. Moreover, hand performed testing takes the same amount of time each time it is performed and doesn't enjoy the incremental aspect of automated testing. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Do you know of a much simpler way of writing a program that writes a program?
On May 2, 3:50 pm, mcse jung <[EMAIL PROTECTED]> wrote: > Here is asample program that writes a program and then executes it. > Do you knowof a much simpler way of writing a program that writes a program? Use a templating engine, such as Cheetah: http://www.cheetahtemplate.org/ Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Java or C++?
On Apr 21, 3:14 pm, NickC <[EMAIL PROTECTED]> wrote: > On Apr 15, 1:46 pm, Brian Vanderburg II <[EMAIL PROTECTED]> > wrote: [...] > Yeah, C++ does try to be helpful, and all of those automatic copy > constructor, assignment operator and destructor implementations screw > up royally when confronted with pointers (and being able to use > pointers is basically the whole reason for bothering to write anything > in C or C++ in the first place). Code which relies on these default > method implementations is almost certain to be rife with memory leaks > and double-free bugs. So instead of being a convenience, they become a > painfully easy way of writing code that silently does some very, very > wrong things. When a class includes a pointer data member, there is no single, right way to handle it. C++ automatically generated member functions are defined so as to be consistent in dealing with *values*. Any C++ programmer that hasn't learnt this simple fact, shouldn't be trusted with any programming language. Python and especially Java will only make it harder to spot the mess he is making. > Other things like methods (including destructors!) being non-virtual > by default also make C++ code annoyingly easy to get wrong (without it > obviously looking wrong). I can see how that might be confusing for programmer coming from Python, but it's more natural for those coming from C. > The whole design of C++ is riddled with premature optimisation of > speed and memory usage in the default settings, instead of choosing > safe defaults and providing concise ways of allowing the programmer to > say "I know optimisation X is safe here, please use it". I absolutely agree. > And the result? Any serious project in the language has to adopt it's > own techniques for avoiding all those traps, and those techniques are > likely to eliminate any supposed optimisations provided by the choices > of the C++ committee, while filling a code base with boilerplate that > only exists for the purpose of working around defects in the language > design (Scott Meyers has written at length about the worst of these > issues, far more clearly and eloquently than I ever could [1]). Did you give up on C++ in the early nineties? Things have changed a lot since then. Many standard/commonly accepted solutions to the problems you mention can be found in the C++ standard library and in Boost (http://boost.org). With std::vector and boost::shared_ptr you can go an extremely long way without giving pointers any special considerations. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: subprocess module is sorely deficient?
On Apr 22, 12:52 pm, Harishankar <[EMAIL PROTECTED]> wrote: > Hi, > > Sorry to start off on a negative note in the list, but I feel that the Python > subprocess module is sorely deficient because it lacks a mechanism to: > > 1. Create non-blocking pipes which can be read in a separate thread (I am > currently writing a mencoder GUI in Tkinter and need a full fledged process > handler to control the command line and to display the progress in a > text-box) I suggest you check out this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 26, 2:23 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > On Feb 26, 6:58 am, Paul Boddie <[EMAIL PROTECTED]> wrote: > > > The Lisp > > scene has also been plagued by an unnecessary deference to commercial > > interests, which means that the hottest topic on comp.lang.lisp right > > now is probably Paul Graham's much-anticipated but arguably > > disappointing Lisp "successor", Arc, amongst the usual in-fighting and > > parade-dampening. > > It looks like his main contribution was to get rid of superfluous > parentheses. Which, admittedly, is no small thing for Lisp. Guido already did that, didn't he? ;-) Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 25, 3:59 pm, Sebastian Kaliszewski <[EMAIL PROTECTED]> wrote: [...] > 1. Your "generic" resource-management infrastructure is not generic to begin > with! It does not work for mutually dependant resources. How so? Could you give a concrete example? > 2. Your "generic" infrastructure increases burden on the programmer > everywhere any resorce (including trivial one like memory) is used, while > GC kills that burden in 95% of the cases. C++ish approach puts the notion > of ownership everywhere - both in 95% of cases where it's useless and in > remaining 5% where it's actually needed. That's not reduced effort by any > means. Like others around here you seem not to be aware of the existence of the standard C++ library. That and local variables usually deal with well over half the cases of memory management in any non trivial application, and boost::shared_ptr can deal with a good portion of the rest. > 3. You can't handle clean-up errors in reasonable way in C++ish approach, so > anything more complex should not by handled that way anyway. So it's okay for a Python mechanism to deal with 95% of the cases, but not for a C++ one? At least in C++ resource management only becomes more complicated if you need more control. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 24, 5:25 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > Jeff Schwab <[EMAIL PROTECTED]> writes: > > > there's actually a published book specifically about C++ pitfalls. > > > Mercy, a whole book? > > http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=97802... Read the title. This is about "C Traps and Pitfalls". Although it shows its age, it's still worth reading. Unfortunately from its price you'd think it was handwritten. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 26, 12:58 pm, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 25 Feb, 19:44, Nicola Musatti <[EMAIL PROTECTED]> wrote: > > > > > Witness the kind of > > libraries/framework that used to and still come with some commercial C+ > > + implementation, and even some free/open source ones; Boost, ACE and > > wxWidgets are the first that come to mind. > > Oh, that's another good reason for C++'s decline: the fragmentation of > the development community through a plethora of proprietary products, > each one with its advocates and a relatively small common ground > (admittedly growing over the years thanks to Free Software and > standards) between them all. When Java came along, even though the > best GUI offering was AWT, it was better than nothing and it was one > of the batteries included. Although Sun's Java was also proprietary, > it was easier for people to obtain and redistribute, often without per- > seat or per-unit licensing costs. C++ was born and acquired its popularity in a period when freely available software wasn't as common as it is today and corporation didn't see any kind of advantage in investing in it. By the way, funny you should mention AWT, given how it was soon superceded by Swing, which in turn competes against SWT. And given the state of the Python web framekork scene if I were you I'd start looking for another language ;-) Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 25, 3:17 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > On Feb 25, 8:29 am, Nicola Musatti <[EMAIL PROTECTED]> wrote: > > > On Feb 24, 9:14 pm, Larry Bugbee <[EMAIL PROTECTED]> wrote: > > > Corporate marketing, and corporate attention in general, saw to it > > > that Java was well equipped with libraries and frameworks addressing > > > enterprise application needs. ...but the *big* reason Java won over C+ > > > + is because your application became stable sooner. ...with arguably > > > fewer problems later. > > > The number of libraries you get "out of the box" appear to me as more > > likely explanations for the productivity increase. > > The productivity increase of the language appears to me as a more > likely explanation for the number of libraries you get "out of the > box". In the case of Python I suspect you have a point even without the smiley, given how much of what's available was developed without any major corporation's support. On the other hand, had the kind of money that's been poured into Java and/or .NET been poured into *standard* C+ +, I dont' think it would be so far behind. Witness the kind of libraries/framework that used to and still come with some commercial C+ + implementation, and even some free/open source ones; Boost, ACE and wxWidgets are the first that come to mind. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 24, 9:14 pm, Larry Bugbee <[EMAIL PROTECTED]> wrote: > On Feb 21, 10:22 am, Nicola Musatti <[EMAIL PROTECTED]> wrote: > > > On Feb 21, 6:31 pm, Paul Boddie <[EMAIL PROTECTED]> wrote: > > > > The main reason why C++ has declined in usage is because almost > > > everything of practical value is optional. > > No, disagree. > > > The main reason why C++ has declined in usage is because it never got > > the kind of corporate marketing enjoyed by Java and C#. > > I'm inclined to disagree for two reasons. C++ is a very complex > language. Java (and the later C#) less so. Couple that with reduced > debugging time due to garbage collection and fewer pointer problems, a > lot of us decided a factor of 2x in personal productivity was worth > it. Runtime was initially an impediment, and still is for desktop > applications, but the trade was worth it. While this was probably true towards the end of the nineties, given the standard library and Boost I find it hard to believe that a similar increase can be accounted for just in terms of language differences. > Corporate marketing, and corporate attention in general, saw to it > that Java was well equipped with libraries and frameworks addressing > enterprise application needs. ...but the *big* reason Java won over C+ > + is because your application became stable sooner. ...with arguably > fewer problems later. The number of libraries you get "out of the box" appear to me as more likely explanations for the productivity increase. > And the migration to Python is due in large part because of an > additional factor of 3-4x in personal productivity (over Java). > Improvements in runtime performance wouldn't hurt, but for many > applications that's not an issue. (If optional data typing were > offered, Python's penetration in the enterprise space would be even > higher, and I suspect there would be performance gains as well.) This I found less hard to believe. Python is more expressive than Java and usually requires less code for the same task. Moreover tha availability of libraries is comparable. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 24, 1:01 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
> Nicola Musatti <[EMAIL PROTECTED]> writes:
> > >>>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
> > [...]
> > > There you replace one line of code with 40+ lines to get around the
> > > absence of GC. Sounds bug-prone among other things.
>
> > Come on, you didn't define f, g, izip, h or frob either. It's more
> > like 5 to one. Furthermore your code is more compact due to the
> > existence of list comprehensions, not because of GC. Had you written a
> > loop the difference would be smaller.
>
> No I don't need a loop if I don't use the listcomp. I could say
>
> a = map(lambda x,y: f(x)+g(y), ifilter(lambda x,y: h(x,y).frob==7,
>izip(m1, m2)))
>
> the listcomp is basically syntax sugar for that.
>
> The issue here is that Python is simply more expressive than C++,
> which doesn't support creation of higher order functions like that.
I see. The C++'s closest equivalent would probably be something like
int func(int x, int y) { return f(x) + g(y); }
bool filter(int x, int y) { return h(x,y).frob() == 7; }
transform_if(m1.begin(), m1.end(), m2.begin(),
std::back_inserter(a), func, filter);
Assuming that instead of izip you had the following, which is more in
style with how the C++ standard library usually works:
template
inline void transform_if(InIter1T begin1, InIter1T end1,
InIter2T begin2, OutIterT out, FuncT func, FilterT filter)
{
while ( begin1 != end1 )
{
if ( filter(*begin1, *begin2) )
*out++ = func(*begin1, *begin2);
++begin1;
++begin2;
}
}
Nameless, local function definitions and a form of type inference
should officially become part of C++ in little over a year. These will
help achieve closer expressiveness for similar statements, but the
lack of native tuples in the language will probably make it impossible
to get much closer.
> However, one of the consequences of programming in this style is
> you allocate a lot of temporary objects which best managed by GC.
According to which metric? This statement appears as totally
gratuitous to me. You seem to forget that deallocation of local
objects only entails stack readjustment. You can hardly beat that with
dynamic memory management.
Cheers,
Nicola Musatti
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Paul Rubin wrote:
> Nicola Musatti <[EMAIL PROTECTED]> writes:
>>>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
[...]
> There you replace one line of code with 40+ lines to get around the
> absence of GC. Sounds bug-prone among other things.
Come on, you didn't define f, g, izip, h or frob either. It's more like
5 to one. Furthermore your code is more compact due to the existence of
list comprehensions, not because of GC. Had you written a loop the
difference would be smaller.
>> int f(int n) { return n * 2; }
>> int g(int n) { return ( n * 2 ) + 1; }
>
> That is not a reasonable translation, since you've assumed the output
> of f and g are integers that don't need to be dynamically allocated.
> Maybe in the Python example, f and g and x and y are all bignums or
> matrices or something like that.
In my example I return a map by value just to show that it can be
generalized to more complex data types. This is not C: in C++ you can go
a long way without allocating dynamic memory explicitly. In my example
std::map and std::vector do it for me.
Cheers,
Nicola Musatti
--
Nicola.Musatti gmail com
Home: http://nicola.musatti.googlepages.com/home
Blog: http://wthwdik.wordpress.com/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Marc 'BlackJack' Rintsch wrote: [...] > Or are used to think of OOP as a graph of objects that are communicating > with each other. In the value type style you are "talking" to copies of > objects all the time which I find a bit confusing because *I* have to keep > track of which maybe not so identical twin brother of an object I'm > talking at each point. But C++ gives you both; you use values for things that have equality but not identity and (smart) pointers for the opposite case. > Also it seems odd to me to copy large collections around instead of > passing references. Your `izip()` creates a quite small `map` -- what > about big ones. With mutable objects!? True, and in a serious application I'd probably pass the map by reference into the function. Still, it's rather likely that these copies are optimized away by the compiler; this is what VC++ does, for instance. Cheers, Nicola Musatti -- Nicola.Musatti gmail com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 22, 5:13 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > On Fri, 22 Feb 2008 04:48:28 -0800, Nicola Musatti wrote: [...] > > As you can see the standard library takes care of all memory > > management. > > Aaah, that's much nicer and easier to understand than the list > comprehension. After this great example I'll switch to C++. ;-) You should. As you can see C++ is way more explicit than Python ;-) > > But somehow you still manage memory by writing in a style that favors > value types. Certainly, but this is a natural C++ programming style, at least for those that aren't too deeply rooted in their C heritage. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 22, 3:25 pm, Roy Smith <[EMAIL PROTECTED]> wrote: > In article > <[EMAIL PROTECTED]>, > Nicola Musatti <[EMAIL PROTECTED]> wrote: > > > Yet I'm convinced that even such partial guarantee is worth having. > > Partial guarantees are like being a little bit pregnant. Yes, and I'm sure your tests cover all possible paths through your code. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 22, 12:07 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
> Nicola Musatti <[EMAIL PROTECTED]> writes:
> > In C++ memory is just another resource which you can handle just like
> > any other one, possibly using RAII.
>
> Ok, I'll bite. Here's a straightforward Python expression:
>
>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
>
> Consider how many intermediate objects are being allocated in figuring
> out that listcomp. Do you REALLY want to manage all the deallocation
> with something like RAII?
What makes you think that a translation of a similar expression would
involve explicit dynamic allocation at all? Barring bugs, here's an
equivalent example:
#include
#include
#include
int f(int n) { return n * 2; }
int g(int n) { return ( n * 2 ) + 1; }
std::map izip(int i, int j) {
std::map m;
m[i] = j;
m[j] = i;
return m;
}
class A {
int i, j;
public:
A(int ii, int jj) : i(ii), j(jj) {}
int frob() { return i + j; }
};
A h(int i, int j) { return A(i, j); }
int main() {
int m1 = 3;
int m2 = 4;
std::vector a;
std::map m = izip(m1, m2);
for ( std::map::iterator i = m.begin(); i != m.end(); ++i )
{
if ( h(i->first, i->second).frob() == 7 )
a.push_back(f(i->first) + g(i->second));
}
for ( std::vector::iterator i = a.begin(); i != a.end(); ++i )
std::cout << *i << '\n';
}
As you can see the standard library takes care of all memory
management.
Cheers,
Nicola Musatti
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 22, 12:09 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > Nicola Musatti <[EMAIL PROTECTED]> writes: > > The real point about garbage collection is that it's about the only > > way to ensure that an object of one type is never taken to be of > > another type, e.g. by keeping around pointers to the object that > > occupied its memory before it was reallocated. I believe that this > > degree of type safety is worth having, which is why I favour the > > addition of optional GC to C++. > > But in C++, garbage collection makes no such guarantee. Think of > out-of-range subscripts. I'm aware that the guarantee would not be perfect. For instance another source of problems could be holding pointers to local variables that went out of scope. Yet I'm convinced that even such partial guarantee is worth having. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 22, 9:03 am, Bruno Desthuilliers wrote: > Nicola Musatti a écrit : [...] > > So, yes, your big company is > > likely to be safer with newbie C++ programmers than with Python newbie > > programmers. > > Sorry but I don't buy your arguments. I suspect nobody seriously does, not even in C++ newsgroups ;-) > > Had we been speaking of productivity... but we weren't, were we? > > Should we ?-) Oh, I'm convinced that Python wins in many contexts, but I believe that it has more to do with the number of batteries that come with the package rather than to its being a dynamically typed language. Is this controversial enough? ;-) Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 22, 1:17 am, Jeff Schwab <[EMAIL PROTECTED]> wrote: [...] > If you've already got a generic, language-supported way to manage > resources (like RAII with deterministic destruction), then why bother > with garbage collection? I'm not trying to knock it; it was a big step > up from C-style "who forgot to delete a pointer" games. It just seems > to me like a solution to something that's no longer a problem, at least > in well-written C++ code. I'll take destructors over GC any day. The real point about garbage collection is that it's about the only way to ensure that an object of one type is never taken to be of another type, e.g. by keeping around pointers to the object that occupied its memory before it was reallocated. I believe that this degree of type safety is worth having, which is why I favour the addition of optional GC to C++. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 22, 12:24 am, Carl Banks <[EMAIL PROTECTED]> wrote: > On Feb 21, 1:22 pm, Nicola Musatti <[EMAIL PROTECTED]> wrote: > > > There are other downsides to garbage collection, as the fact that it > > makes it harder to implement the Resource Acquisition Is > > Initialization idiom, due to the lack of deterministic destruction. > > That's not a downside: it's at least a wash. > > In C++ you manage memory and the language manages resources. In > Python you manage resources and the language manages memory. > > RAII is merely one way of minimizing complexity. Garbage collection > is another way. In C++ memory is just another resource which you can handle just like any other one, possibly using RAII. GC deals with memory very reasonably, but makes it more complicate to deal with other resources. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Paul Boddie wrote: > On 21 Feb, 19:22, Nicola Musatti <[EMAIL PROTECTED]> wrote: [...] > > The main reason why C++ has declined in usage is because it never got > > the kind of corporate marketing enjoyed by Java and C#. > > What? C++ was practically the favoured language for serious > applications development on the win32 platform for a good decade. It > was all about Visual C++/Studio until Microsoft dabbled with J++, got > sued and eventually came up with C# (and Managed C++). You can't > really ask for a more influential patron than Microsoft. You're partly right, but there are a couple of things to consider: first, at the time the language wars hadn't started yet. As you say when Sun came out with Java Microsoft first tried to jump on the bandwagon on its own terms, then invented .NET. Don't forget that Visual Studio stuck at the 6.0 release for about 5 years. Second, what Microsoft pushed at the time was their own notion of C++, centred around the MFC framework. People used to say that there were C++ programmers *and* Visual C++ programmers. [...] > > Sorry, but although this was probably true in the early 90's that's > > not the way it goes in practice nowadays, thanks to automatic > > variables, destructors, the standard library containers and smart > > pointers. > > Yes, but support for a lot of this stuff usually lags behind the best > practices, so there are usually the tools that actually do attempt to > provide this stuff, then there are the tools which people have to use > (such as Visual Studio) and which don't work satisfactorily, although > I'll admit that the situation was improving (on the Free Software > side, at least) when I last had anything to do with C++ in a project. Things have changed a lot in the last six years. VC++ and g++ are both very good C++ compilers, quite close to standard compliance and both moving to anticipate the next version of the standard itself. > Sadly, it took most of the 1990s for widespread support for several > key C++ features to become available. The joke always used to be about > templates and exceptions, but I've had pages full of bizarre errors > from libraries like Boost more recently than the 1990s. And I've seen > plenty of libraries this century which probably don't follow the best > practices, possibly because the people involved have no faith in the > language implementations. Both VC++ and g++ support Boost quite well nowadays, with way fewer workarounds than were required a few years ago. Note that basic things like shared_ptr have been working well on most C++ compilers for at least five years. The real sad thing is that nobody is likely to convince Guido to turn CPython into C++Python ;-) Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 21, 6:31 pm, Paul Boddie <[EMAIL PROTECTED]> wrote: [...] > The main reason why C++ has declined in usage is because almost > everything of practical value is optional. The main reason why C++ has declined in usage is because it never got the kind of corporate marketing enjoyed by Java and C#. > Meanwhile, those C++ > newbies we were talking about are having to deal with decisions that > everyone else can quite happily ignore, knowing that the right choice > has probably already been made for them, where automatic memory > management is probably the right choice for the biggest decision of > them all, as Java demonstrated quite successfully to the hordes of > enterprise programmers (and their managers) at the end of the 1990s. A choice that is available to C++ programmers too, altough I admit it's not a common one and does usually require an external library. As to it being the right choice it's debatable: it took Java something like ten years to come out with usable GUI applications and, judging from many articles and postings across the internet memory management *is* an issue with Java, especially for long running applications. There are other downsides to garbage collection, as the fact that it makes it harder to implement the Resource Acquisition Is Initialization idiom, due to the lack of deterministic destruction. Other languages, such as Python and C#, are recognizing this fact and provide the with/using statement, which serves this purpose but is definitely more clumsy. > Back to those C++ newbies, then. Of course, none of them pushed into a > C++ project is going to have much say about which memory management > "best practice" is going to be used - the decisions are already set in > stone by the project - and so it's all about coping with the tedious > tracking of "who owns which pointer" and hoping that different > libraries don't have different policies. Taking the quotes out of > order... Sorry, but although this was probably true in the early 90's that's not the way it goes in practice nowadays, thanks to automatic variables, destructors, the standard library containers and smart pointers. > > At least C++ programmers tend to know that memory > > must be managed, while newbies in other languages are often lead to > > believe - wrongly - that the garbage collector takes care of > > everything. > > Sure, there are some issues with memory consumption patterns with > various garbage collectors, but the "it's good for you" attitude has > scant justification unless you're dealing with constrained > environments. It's not just a matter of memory consumption patterns, it's also a question of explicitly resetting your memory references to ensure that the GC can reclaim them. This can be less than obvious when complex data structures and/or callback objects are involved. > And even with people watching the dials in their C++ > application, you still get obscene resource misuse, which is why > Firefox eventually consumes over 1GB memory on this desktop. There are > considerably fewer caveats involved with regard to languages with > garbage-collected runtime environments. Unfortunately C++ by itself cannot ensure that only top programmers use it ;-) > I seem to remember that Hans Boehm had some interesting observations > about garbage collection myths, especially around performance, but > since the mindset persists in large tracts of the C++ development > landscape that it must somehow be cheating to use a garbage collector, > I suppose we still have a few more years of applications accessing the > wrong memory locations and showing the usual useless backtrace > dialogues for submission to uninterested developers who insisted on > using C++ because "everything else is slow". Things change. Boehm himself is working for the inclusion of - optional - garbage collection in the C++ standard. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: understaning "self"
On Feb 21, 2:34 pm, "Poppy" <[EMAIL PROTECTED]> wrote: > I've been searching online to try get a better understanding of what "self" > does when I define this parameter in my class functions. All I'm finding is > debates on whether "self" has any value to the language but that doesn't > help me in my newbie question. So the code excerpt below is from "Beginning > Python" Norton, Samuel, Aitel, Foster-Johnson, Richardson, Diamon, Parker, > and Roberts. > > What I think "self" is doing is limiting the function call to only function > in "this" class. So in the function below "has" calls self.has_various(), if > I had a function called "has_various" in my program or another included > class using "self" insures that the "has_various" below is the one used. Am > I correct in my understanding? I'll try to explain with as simple an example as I can think of. First of all, 'self' is just a conventional name, it isn't a keyword and has no special meaning per se. You could just as easily write: In [10]: class A(object): : def __init__(this, n): : this.n = n : : def f(me): : print me.n : : In [11]: a = A(42) In [12]: a.f() 42 The point is that when you write a statement such as a.f() the interpreter uses 'a' in two ways: first, to find which function f() to call; second, as a parameter to f() itself. The conventional 'self' helps you remind that the first argument is going to be the instance of the class on which the function f() is going to be called. You can actually separate the two uses above with the following equivalent call: In [13]: A.f(a) 42 Here you tell the interpreter which function f() to call by specifying its class, A, and you pass it 'a' explicitly as an argument. One could argue that the C++/Java/C# approach where you don't specify the current instance as an argument, but can optionally use the 'this' keyword to refer to it is more convenient; however the explicit 'self' makes it possible for free functions and class methods to work in exactly the same way. This in turn makes the language more consistent and makes some more advanced, very effective techniques possible. Hope this helps. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 21, 5:14 pm, Steve Holden <[EMAIL PROTECTED]> wrote: > Ryan Ginstrom wrote: > >> On Behalf Of Nicola Musatti > >> Newbies learn, and the fundamental C++ lessons are usually > >> learnt quite easily. Unless we're talking about idiots, that > >> is, but in this case at least C++ is likely to make their > >> deficiencies evident sooner than most other programming > >> languages. So, yes, your big company is likely to be safer > >> with newbie C++ programmers than with Python newbie programmers. > > > The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly > > language. Java I might go along with, but C++? [...] > I think you can safely assume that an tag pair should > have surrounded Nicola's assertion. To an extent, certainly. As not all companies can afford to hire only the best, you do have to cater for newbies. The way to do it, however, is not to provide them with "sandbox" languages [1], but rather to ensure that they acquire experience as quickly as possible and that they aren't in a position to do more damage than expert programmers through their inexperience. To this purpose mentoring, tests and code inspections appear to me as more effective tools than a garbage collector. Still, suppose you were to choose a team of swimmers that had to be ready for a tough task in a short time; the first time around, would you push them into the swimming pool with or without a life jacket? The trouble with C++ is that at times it takes you sooo long to drown ;-) Cheers, Nicola Musatti [1] I'm not thinking of any specific language, but rather to the notion that some languages are inherently "safe". -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 21, 4:00 pm, Tim Chase <[EMAIL PROTECTED]> wrote: > > Newbies learn, and the fundamental C++ lessons are usually > > learnt quite easily. > > Ah yes...that would be why Scott Meyers has written three > volumes[1] cataloging the gotchas that even experienced C++ > programmers can make... Scott Meyers's books don't just catalogue gotcha's, but suggest effective ways to use the language. Moreover their combined word count is probably below the "Python Cookbook"'s one. > And the 1030 page Stroustrup C++ reference is easily comprehended > by the uninitiated[2]. The Python core language is a mere 97 > pgs. The documentation for the *entire* standard library is > about the size of just the C++ Language Reference.[3] A more reasonable comparison would be against the core portion of the C ++ standard. This is still roughly three times the Python Reference Manual. The C++ syntax is way more complex than Python's and mostly due to its C heritage is also often inconsistent. However, despite its apparent semplicity, Python allows extremely advanced programming techniques. I wouldn't be surprised if the proportion of Python programmers that are capable of exploiting the language's full power was comparable to the corresponding proportion of C++ expert programmers. While I find the Python standard library documentation adequate for a free, voluntary effort, I consider it one of the weakest spots of Python as a professional tool. Still comparing its size against Stroustrup's book's is really comparing apples with oranges. > Assembly language is pretty easy to learn too. But is it a > productive use of a programmer's time? Only if it's 1975. It depends on the task at hand. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 21, 3:46 pm, "Ryan Ginstrom" <[EMAIL PROTECTED]> wrote: > > On Behalf Of Nicola Musatti > > Newbies learn, and the fundamental C++ lessons are usually > > learnt quite easily. Unless we're talking about idiots, that > > is, but in this case at least C++ is likely to make their > > deficiencies evident sooner than most other programming > > languages. So, yes, your big company is likely to be safer > > with newbie C++ programmers than with Python newbie programmers. > > The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly > language. Java I might go along with, but C++? Memory *leaks* are just as common in garbage collected languages if not more, thanks to C++'s deterministic destruction and its standard library, especially if complemented with smart pointers such as Boost's shared_ptr. At least C++ programmers tend to know that memory must be managed, while newbies in other languages are often lead to believe - wrongly - that the garbage collector takes care of everything. Dereferencing invalid pointers however is indeed a more serious problem. This is the one lesson I had in mind when I wrote my previous message; newbies that are not hopeless tend to learn it rather quickly and the number of mistakes of this kind they make tends to fall in a rather short time. I do admit however that even experienced programmers make similar errors every now and again. While attempting to dereference a null reference is a rather common mistake in languages such as Java and C# - I'm not sure about Python - the one invaluable guarantee provided by the garbage collector is the absence of *invalid* references. This is one of the reasons why there's an ongoing effort to add garbage collection to the C++ standard, albeit in an optional form. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Please do not reply personally to newsgroup postings, thank you. On Thu, Feb 21, 2008 at 4:00 PM, Tim Chase <[EMAIL PROTECTED]> wrote: [...] -- Nicola.Musatti gmail com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Feb 21, 10:55 am, Bruno Desthuilliers wrote: > Carl Banks a écrit : [...] > > C++ is a compile-time, type-checked language, which means it is > > totally safer for newbies than Python. Yep, your big company is > > totally safe with newbie C++ programmers. > > Mouarf ! Brillant demonstration, thanks Carl !-) > > (and BTW, +1 QOTW) Newbies learn, and the fundamental C++ lessons are usually learnt quite easily. Unless we're talking about idiots, that is, but in this case at least C++ is likely to make their deficiencies evident sooner than most other programming languages. So, yes, your big company is likely to be safer with newbie C++ programmers than with Python newbie programmers. Had we been speaking of productivity... but we weren't, were we? Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Who's to blame?
On Jan 4, 3:12 pm, [EMAIL PROTECTED] wrote: [...] > I have sub-classed wx.Dialog to do my own custom modal dialogs as > well. You can use sizers and put whatever widgets you want onto it > that way. Just make sure that when you create the Yes/No buttons, you > give them the wx.ID_YES or wx.ID_NO ids, rather than -1 or wx.ID_ANY. > > yesBtn = wx.Button(parent, wx.ID_YES, 'Yes') > noBtn = wx.Button(parent, wx.ID_NO, 'No') As far as I understand this should be taken care of by the XRC/ wxStdDialogButtonSizer combination. Anyway, I solved my problem by binding the following event handler to both buttons: def OnButton(self, event): if self.IsModal(): self.EndModal(event.GetId()) By the way, my assumption above appears to be supported by the fact that a call to ShowModal() on my dialog does return wx.ID_YES when I press the Yes button. I'm still a bit puzzled, but right now I can't afford to let it bother me too much. Thanks for your help! Cheers, Nicola -- http://mail.python.org/mailman/listinfo/python-list
Re: Who's to blame?
Hallo, Mike. First of all, thanks to both you and Rob for your answers. I now see that the wxPython group would have been a better place to post to, all the more so given the tight connection between the wxPython and wxWidgets projects, of which at first I wasn't aware. On Jan 3, 8:19 pm, [EMAIL PROTECTED] wrote: [...] > I've never created a modal dialog like this. Instead, I follow the > wxPython in Action book examples (most of the time), which would do a > yes/no dialog like this: > > > > dlg = wx.MessageDialog(None, 'Some Message', 'A Message Box', > wx.YES_NO | wx.QUESTION) > retCode = dlg.ShowModal() > if retCode == wx.ID_YES: ># do something >print 'yes' > else: ># do something else >print 'no' > dlg.Destroy() > > Actually my example started out as something like if wx.MessageBox(message="Some message", caption="Some caption", style=wx.YES|wx.NO) == wx.YES: pass I had to change it because the actual message can become very long, so I assembled a dialog with a scrollable text field. Maybe I'm expecting to much of wxStdDialogButtonSizer, but I still feel that given that both your method and mine above work straight away, it should provide the same behaviour with Yes/No buttons as with OK/Cancel ones. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Who's to blame?
Hallo, First of all I apologize for the longish example at the bottom, but the biggest source file is automatically generated and I didn't want to modify more than strictly necessary. Also, it would be shorter if XML wasn't so verbose ;-) The following is a wxPython/XRC toy program with a form with a button which, when pressed, causes a simple dialog to be displayed. The problem lies in the fact that apparently ShowModal() does not return when either the Yes or the No buttons are pressed. Curiously, if you change the Yes and No buttons with the OK and Cancel ones that are currently commented everything works as expected. As the sbs_test_xrc.py file below is automatically generated by wxPython 2.8.6.1's XRCed tool from a XRC file which in turn is generated by wxFormBuilder (http://wxformbuilder.org/), I really cant figure out to whom I should report this problem, assuming I'm not missing some obvious mistake of mine, that is. Thanks for your help. Cheers, Nicola Musatti # sbs_test.py import wx import sbs_test_xrc class MainFrame(sbs_test_xrc.xrcMainFrame): def __init__(self, parent): sbs_test_xrc.xrcMainFrame.__init__(self, parent) self.button.Bind(wx.EVT_BUTTON, self.OnButton) def OnButton(self, event=None): d = sbs_test_xrc.xrcDialog(self) ##if d.ShowModal() == wx.ID_OK: if d.ShowModal() == wx.ID_YES: self.Close() class Application(wx.App): def OnInit(self): self.frame = MainFrame(None) self.frame.Show() self.SetTopWindow(self.frame) return True if __name__ == '__main__': app = Application() app.MainLoop() # sbs_test_xrc.py # This file was automatically generated by pywxrc, do not edit by hand. # -*- coding: UTF-8 -*- import wx import wx.xrc as xrc __res = None def get_resources(): """ This function provides access to the XML resources in this module.""" global __res if __res == None: __init_resources() return __res class xrcDialog(wx.Dialog): def PreCreate(self, pre): """ This function is called during the class's initialization. Override it for custom setup before the window is created usually to set additional window styles using SetWindowStyle() and SetExtraStyle().""" pass def __init__(self, parent): # Two stage creation (see http://wiki.wxpython.org/index.cgi/TwoStageCreation) pre = wx.PreDialog() self.PreCreate(pre) get_resources().LoadOnDialog(pre, parent, "Dialog") self.PostCreate(pre) # create attributes for the named items in this container self.wxID_YES = xrc.XRCCTRL(self, "wxID_YES") self.wxID_NO = xrc.XRCCTRL(self, "wxID_NO") class xrcMainFrame(wx.Frame): def PreCreate(self, pre): """ This function is called during the class's initialization. Override it for custom setup before the window is created usually to set additional window styles using SetWindowStyle() and SetExtraStyle().""" pass def __init__(self, parent): # Two stage creation (see http://wiki.wxpython.org/index.cgi/TwoStageCreation) pre = wx.PreFrame() self.PreCreate(pre) get_resources().LoadOnFrame(pre, parent, "MainFrame") self.PostCreate(pre) # create attributes for the named items in this container self.button = xrc.XRCCTRL(self, "button") # Resource data -- def __init_resources(): global __res __res = xrc.EmptyXmlResource() wx.FileSystem.AddHandler(wx.MemoryFSHandler()) sbs_test_xrc = '''\ wxDEFAULT_DIALOG_STYLE 2 2 0 0 1 wxEXPAND 5 wxALIGN_CENTER_HORIZONTAL|wxALL 5 &Yes wxALIGN_CENTER_HORIZONTAL|wxALL 5 &No
Re: The best platform and editor for Python
On Jul 5, 4:21 pm, Roy Smith <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Nicola Musatti <[EMAIL PROTECTED]> wrote: > > > On Jul 5, 1:23 pm, Gregor Horvath <[EMAIL PROTECTED]> wrote: > > [...] > > > That's a property of open source projects. > > > Features nobody really needs are not implemented. > > > No, no, you got it all wrong. It's in *commercial* projects that > > features nobody really needs are not implemented. > > No, no, squared. In a commercial project, the only features that get > implemented are the ones somebody is willing to pay for. Whether there is > any correlation between need and willingness to pay is an open question. Ah, but you snipped the most important part of my post: > Profit is fundamental in convincing you that you really > need the features. I mean, marketing is all about creating the willingness by stimulating the perception of the need. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: The best platform and editor for Python
On Jul 5, 1:23 pm, Gregor Horvath <[EMAIL PROTECTED]> wrote: [...] > That's a property of open source projects. > Features nobody really needs are not implemented. No, no, you got it all wrong. It's in *commercial* projects that features nobody really needs are not implemented. Profit is fundamental in convincing you that you really need the features. On the other hand open source projects tend to lack features nobody enjoys implementing. Cheers, Nicola Musatti P.S. Maybe I should add a ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: c++ for python programmers
On Feb 14, 2:41 pm, Neil Cerutti <[EMAIL PROTECTED]> wrote: [...] > Don't forget the lack of standard garbage collection. Optional garbage collection is highly likely to be included in the next C++ standard, due out in a couple of years. > Also there's the hell known as exception safety. > > Python conceptually has many of the same issues with exception > safety, but at least memory leaks aren't one of the consequences. > I imagine most Python programmers don't even think about > exception safety, but probably should be. We just happily raise > exceptions willy-nilly, without worrying about our objects > remaining in a reasonable state. Or do we? Maybe it's better not > to think about it. ;-) On the other hand having everything dynamically allocated prevents the adoption of deterministic destruction, which is a far better clean up mechanism than try/finally clauses. In modern C++ standard containers and smart pointers help solve most memory related problems. I'm aware that most is not the same as all, but on the other hand garbage collection has it's problems too: depending on the algorithm it may not be able to reclaim all the unreachable memory and forgetting to explicitly reset variables may lead to hanging to memory that is really not needed anymore. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: c++ for python programmers
On Feb 14, 12:26 am, Sam <[EMAIL PROTECTED]> wrote: [...] > C++ is -not- strongly typed. You can cast anything to void *, and > manipulate it in ways unimaginable. Plus there's the whole mess that > is pointer arithmetic and a weak typesystem... The previous poster wrote "strongly typed", not "a straight jacket". The fact that you may do certain things doesn't mean that you have to nor that they are going to be done to you against your will. > Disclaimer: I am unashamedly in the "C++ Is Evil" camp, and wholly > believe that if you want proper strong, static type checking, use > Haskell, or if you want proper, complete object-orientation (C++'s > primitive types compromise its object system's integrity, and I > believe I've already discussed casting and pointers), use Python, and > if you want under-the-hood pointer-fu, use C. The trouble is that in addition to proper, strong, static type checking people often also want their daily bread, fancy that. As to the merits of complete object orientation, I'd like to hear about them, because nobody managed to explain them to me in a satisfactory way yet. There are many valid reasons to dislike C++ and to prefer Python to it, but dismissing it as "C++ Is Evil" is just plain stupid. Moreover, C might be a valid competitor for small projects and it probably covers most Pythonistas' needs for "closeness to the metal", but it just doesn't scale. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: c++ for python programmers
On Feb 12, 7:00 pm, "Thomas Nelson" <[EMAIL PROTECTED]> wrote: > I realize I'm approaching this backwards from the direction most > people go, but does anyone know of a good c/c++ introduction for > python programmers? I don't think there's any book catering specifically for people coming from dynamically typed languages. If you want a crash course try "Accelerated C++", by Koenig & Moo; if you want something more gentle, that may also serve as a reference, go for "C++ Primer", by Lippman, Lajoie & Moo. Both books from Addison Wesley. As for something freely available people speak well of Bruce Eckel's "Thinking in C++", but I haven't read it: http://www.mindview.net/ Books/TICPP/ThinkingInCPP2e.html Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Lead Software Engineer
James Stroud wrote: > alex23 wrote: > > Emma wrote: > > > >>5. Please provide us with a comparison of the following music discovery > >> > >>sites: > >> > >>http://www.blogmusik.net > >>http://www.seeqpod.com/music > >>http://www.finetune.com > >>http://www.webjay.com > >> > >>For each of these we like to know: > >>A) What you like and dislike about each of these. > >>B) Which one you like the best. > >>C) Which one you think others might like the best. > >>D) How you would improve the one you like. > > > > > > There _are_ no jobs on offer here. This is just a cheap attempt at > > getting free survey data. > > > > - alex23 > > > > They would get more data if they lowered their expectations for the > programmer position. They would get even more data if they specified where to reply... Unless this is an incredibly lame attempt to increase those sites' traffic. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Grammar parsing
Paolo Pantaleo wrote: > Hi, > > How can I write a pareser for a certain gramamr? I found PyPy that > does it, is thare any other tool? Maybe something built-in the python > interpreter? Check out Dave Beazley's Ply: http://www.dabeaz.com/ply/ . Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: 10GB XML Blows out Memory, Suggestions?
[EMAIL PROTECTED] wrote: > I wrote a program that takes an XML file into memory using Minidom. I > found out that the XML document is 10gb. > > I clearly need SAX or something else? What you clearly need is a better suited file format, but I suspect you're not in a position to change it, are you? Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Standalone Python functions in UML?
bruno at modulix wrote: [...] > Yes, there's in UML a fundamental distinction between classes and > objects - distinction that does not exist in a lot of OO languages. This > greatly limits UML's usability for some common idioms in dynamic OOPL's. > Seems like UML has been designed to express only the restricted subset > of OO supported by rigid static languages like C++, Java and ADA. Moreover, it also seems like UML has been designed to express the restricted OO subset of the paradigms supported by languages like C++ and ADA. And I suspect UML design tools are not that popular within the C and Lisp programming communities... Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Standalone Python functions in UML?
Roman Susi wrote: [...] > Also, my argument that Python is quite good at communicating design > ideas is supported by the fact that Python developers do not use UML (or > other modelling tools/languages) as often as say Java programmers, nor > feel the need to. And probably Python is too dynamic for UML. That is > another reason rountrip tools aren't there. Another reason is probably the problem you started this thread with; UML class diagrams are very much centered around Java style object orientation. Other paradigms, like the procedural and the generic ones, do not fit well. Nor is it well suited to represent the shift to a meta level that is involved when you start creating types at execution time. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: New python.org website
Michael Tobis wrote: [...] > On the other hand, (since I think the design, while not brilliant, is > good) fixing the logo is something that can be achieved without too > much fuss. The obviously perfect logo would be Kaa's face: http://disney.go.com/vault/archives/villains/kaa/kaa.html After all even my two and a half year old kids know that Kaa is *the* python. However I suspect it would take a lot of money to license that. [...] > Finally, I disagree that the current logo is better than the neutral > but consistently used php logo or the very clever java coffee mug logo, > and notably the Ruby on Rails logo, which is first rate. The Java logo has the problem that it is not universal: in Italy for instance the name "Java" has no connection with "coffee". Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: New python.org website
Phoe6 wrote: > beta.python.org evolved very nice and noticed today the new python.org > website going live. There is a change in the look n feel, wherein it > looks "more official" and maximum possible information about python is > now directly accessible from the home page itself. Kudoes to the > design team. Sigh! Another of these sites that all look the same, with two screenfuls of info on the home page that are going to be in the way of every returning user... Not to mention the dull color scheme and the unremarkable logo. I can't say I'm impressed. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Too Many if Statements?
bruno at modulix wrote:
[...]
> Suppose you have to match a line against a list of regexp and log if it
> doesn't match. You could of course repeat the whole code for each
> regexp, ie:
>
> if not re.match(r'a/regexp/here', line):
> log('a first message')
>
> if not re.match(r'another/regexp/here', line):
> log('another message')
>
> (... 150 regexps later ...)
>
> if not re.match(r'150/regexps/later', line):
> log('pfww, getting tired of copy/pasting')
>
> etc...
>
> But you could also factor much of it:
>
> def checkMatch(line, regexp, msg):
> if not re.match(regexp, line):
> log(msg)
>
> then have a list of regexps/messages pairs and:
> for exp, msg in regexps:
> checkMatch(line, exp, msg)
>
> And now, you can add as many thousands regexps you want, you still have
> one (and only one) if in the code (well, in this snippet at least...).
If your checks are this complicated, I think you should consider
writing a parser for your configuration file. If you use a parser
generator it's not that difficult. Moreover a lexical analyzer could be
enough if your syntax is simple. I found Dave Beazley's PLY reasonably
easy to use: http://www.dabeaz.com/ply/
Cheers,
Nicola Musatti
--
http://mail.python.org/mailman/listinfo/python-list
Re: OO conventions
Fredrik Lundh wrote: > Nicola Musatti wrote: [...] > > What is important to me is to keep your get_initial_data() function > > outside Klass if it's task is non trivial, e.g. it has to interact with > > the OS or a DB. > > why ? Separating the internal logic of an application from its interactions with the outside world, e.g. retrieval from a file or a database and presentation to a GUI, makes it easier to reuse the logic in different contexts and may help make it possible to use highly generic solutions for those interactions. I'm thinking of code generation or introspection, which may be applied with very limited knowledge of the application logic. In larger projects I find that this separation tends to match the different areas of expertise that are needed: database experts, GUI experts, domain experts, etc. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: OO conventions
I V wrote: > Nicola Musatti wrote: [...] > > Factory functions (or classes) are there to solve this problem and > > still allow a clean separation of concerns. Although instances of Klass > > are created uninitialized, they only live in this state within their > > factory and only reach trhe outside world only when they are in a > > usable state. > > This may be my limited imagination, but I can't think of a situation > when you would prefer something like: > > def factory(info): > k = Klass() > data = get_initial_data(info) > k.set_data(data) > return k > > to: > > def factory(info): > data = get_initial_data(info) > return Klass(data) > > What would be the value of doing the initialization in a separate > method, rather than the constructor? I didn't express my intent clearly. I agree that in general your second example is to be preferred to the first one. In fact the only reason I could think of using the first scheme is when the second would lead to Klass's __init__ method having a large number of parameters. What is important to me is to keep your get_initial_data() function outside Klass if it's task is non trivial, e.g. it has to interact with the OS or a DB. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: OO conventions
Steven D'Aprano wrote:
[...]
> If a class has a natural, obvious default state (e.g. a mutable string
> class might start off empty, a mutable int class might start off as zero,
> a binary tree might start off as an empty node with no children) then it
> makes sense to initialise the class, then add your data.
>
> But if the class has no natural default state, then it makes no sense to
> create an "empty object" with no data, a "non-image image" so to speak.
I don't think this is all there is to it. Even though a class such as
Image might not have a sensible default, initial state it still might
not be reasonable to burden it with the ability to collect the
information needed to reach such an initial state. To put it it another
way: a car is a car, it isn't a car factory.
> In other words, if you find yourself writing methods like this:
>
> class Klass:
> def foo(self):
> if self.data is None:
> raise KlassError("Can't foo an uninitialized Klass object.")
> else:
> # do something
Factory functions (or classes) are there to solve this problem and
still allow a clean separation of concerns. Although instances of Klass
are created uninitialized, they only live in this state within their
factory and only reach trhe outside world only when they are in a
usable state.
Cheers,
Nicola Musatti
--
http://mail.python.org/mailman/listinfo/python-list
Re: OT: excellent book on information theory
Tim Peters wrote: > [Paul Rubin] > >> I wouldn't have figured out that a "car park" was a parking lot. I > >> might have thought it was a park where you go to look at scenery from > >> inside your car. Sort of a cross between a normal park and a drive-in > >> movie. > > [Grant Edwards[ > > ;) > > > > That's a joke, right? > > Probably not, if Paul's American. For example, here in the states we > have Python Parks, where you go to look at scenery from inside your > python. They're actually one and the same thing: http://v8rx7.com/python_by_fibercan.htm Cheers, Nicola Musatti P.S. The way Google can find anything you look for, no matter how far out, is sort of scary. -- http://mail.python.org/mailman/listinfo/python-list
Re: Spiritual Programming (OT, but Python-inspired)
Peter Hansen wrote: > Steven D'Aprano wrote: > > Life is a process, not a thing -- > > when a clock runs down and stops ticking, there is no essence of ticking > > that keeps going, the gears just stop. When I stop walking, there is no > > spirit of walk that survives me coming to a halt. I just stop walking. > > Yet when one listens to a clock or other repetitive sound for long > enough, when that sound stops one continues to hear a sort of > "after-image" of the sound. > > Somewhat like when someone sings a jingle and you just can't get it out > of your head: > > "plop plop fizz fizz, oh what a relief it is..." > > Perhaps something similar happens with the "ticking" that we call life, > and what happens after death: > > "plop plop fizz fizz, oh what a release this is..." I have an even more eerie (eerier?) example: I rememeber a family friend whose husband had recently died saying that she could still feel his presence about the house. Yet all these examples appear to me to be better explained as instances of a form of physiological or psichological inertia than as indications of the existence of some form of meta reality. More-platonic-than-pythonic-ly y'rs, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Herds of cats (was: Guido at Google)
Cameron Laird wrote: > In article <[EMAIL PROTECTED]>, > Nicola Musatti <[EMAIL PROTECTED]> wrote: > . > >Ah, the closed source days! Back then you could just buy the company > >and be done with it. Now you have to chase developers one by one all > >over the world... ;-) > . > You propellor-heads (I write that in all fondness, Nicola) are > all laughing, but I'm certain that the right elaboration of > that proposition could make it into the *Harvard Business Review* > (or *IBM Systems Journal*, which seems to have tilted irreversibly > in that direction). I was only half joking, actually. Compare Python to Delphi. If a company wanted to acquire control over Delphi, they'd try and buy Borland; to acquire control over Python what are they to do? Well, hiring Guido and Alex is probably a step in the right direction ;-) but would it be enough? Programming languages are not the best example, but if you change it to Mozilla and Opera my argument makes more sense. > Actually, there's already a considerable literature on how pro- > grammers are like other nasty professionals in exhibiting more > loyalty to their community than to their employers. Generalize > as desired. Well, it's still better than PHB's who, in my experience, are only loyal to themselves and in general have more power to put other people's jobs at risk than programmers. Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido at Google
Alex Martelli wrote: > Renato <[EMAIL PROTECTED]> wrote: > > > all of the native administration tools of RedHat (all versions) and > > Fedora Core are written in python (system-config-* and/or > > redhat-config-* ). And even more importantly, yum (the official > > software package manager for Fedora and RHEL) and Anaconda (OS > > installer) are written in Python, too. > > BTW, Chip Turner (from RedHat, and deeply involved in those > developments) happened to start at Google the same day I did;-). Ah, the closed source days! Back then you could just buy the company and be done with it. Now you have to chase developers one by one all over the world... ;-) Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido at Google
Alex Martelli wrote: > Fuzzyman <[EMAIL PROTECTED]> wrote: > > > That's potentially very good news. (Or slightly sinister -depending on > > your paranoia levels). > > > > You got any references on that ? > > I don't think there was any official announcement, but it's true -- he > sits about 15 meters away from me;-). Tsk, tsk, all that brainpower sitting so close together. That's not the way to do risk management! I think you should suggest scattering resources worldwide... now, it just so happens that there's an empty five floor building a block and a half from my home... By the way, I hear that you've become collegues also with Matt Austern, formerly of Apple, and Danny Thorpe, formerly of Borland. I guess we mere mortals don't stand a chance of being hired, but if the trend continues there are going to be a lot of very interesting positions opening everywhere else :-) Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: PYTHON LOOSING FOR JAVA???????
Steven D'Aprano wrote: > Alex Martelli wrote: [...] > Taking a leaf from the various publishers and author's > guilds out there... > > Obviously Google is threatening the profitability of > programmers and their ability to make a honest day's > living. Why would people hire programmers to create new > innovative solutions, when they can just use Google to > search teh Interweb for source code which Google has > stolen from the rightful owners??? > > *wink* The obvious answer is send your CV to Alex... *wink*, *wink* If-you-can't-lick-'em-join-'em-ly y'rs, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
