Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
On Tue, 12 Jun 2012 00:55:38 +0200, Dietmar Schwertberger wrote: > As long as there's no GUI > builder for Python, most people will stick to Excel / VBA / VB. No GUI builder for Python? There are plenty. I use wxGlade with wxPython and it works beautifully. It writes the code for the GUI elements, and I put in the event handlers, database access code and so on. -- http://mail.python.org/mailman/listinfo/python-list
Re: usenet reading
On Sun, 03 Jun 2012 16:25:53 +0200, Matej Cepl wrote: > Yes, Pan is better, but it used to have some rough edges > (e.g., it's offline qualities were a bit elusive) I wouldn't know about that. My connection is always-on. -- http://mail.python.org/mailman/listinfo/python-list
Re: what gui designer is everyone using
On Tue, 05 Jun 2012 10:10:17 -0400, Mark R Rivet wrote: > I want a gui designer that writes the gui code for me. I don't want to > write gui code. what is the gui designer that is most popular? > I tried boa-constructor, and it works, but I am concerned about how > dated it seems to be with no updates in over six years. I'm using wxGlade,and am very happy with it. -- http://mail.python.org/mailman/listinfo/python-list
Re: usenet reading
On Fri, 25 May 2012 15:38:55 -0700, Jon Clements wrote: > > Is there a server out there where I can get my news groups? I use to be > with an ISP that hosted usenet servers, but alas, it's no longer > around... > I use Albasani.net (free and very reliable), as well as gmane.org. Google Groups is an abomination IMHO, and I find it much easier to read mailing lists via a newsreader. I highly recommend Pan, by the way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Just curious: why is /usr/bin/python not a symlink?
On Thu, 23 Feb 2012 19:11:16 +, HoneyMonster wrote: (reformatted (I hope) > $ cd /usr/bin > $ ls -l python* > -rwxr-xr-x 2 root root 9496 Oct 27 02:42 python > lrwxrwxrwx 1 root root 6 Oct 29 19:34 python2 -> python > -rwxr-xr-x 2 root root 9496 Oct 27 02:42 python2.7 > $ diff -s python python2.7 > Files python and python2.7 are identical > $ > > I'm just curious: Why two identical files rather than a symlink? Sorry, my first post didn't format properly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Total newbie question: Best practice
On Tue, 29 Nov 2011 16:57:18 -0500, Dave Angel wrote: > On 11/29/2011 03:06 PM, Colin Higwell wrote: >> Hi, >> >> I am just starting to learn Python (I have been at it only a few >> hours), so please bear with me. I have a few very small scripts (do you >> call them scripts or programs?) which work properly, and produce the >> results intended. >> >> However, they are monolithic in nature; i.e. they begin at the >> beginning and finish at the end. Having done a little reading, I note >> that it seems to be quite common to have a function main() at the start >> (which in turn calls other functions as appropriate), and then to call >> main() to do the work. >> >> Is that standard best practice? >> >> Thanks >> > Welcome to Python, and to the comp.lang.python list. Is this your first > experience programming? > > Yes, factoring your code from "monolithic" to "modular' (several > functions, or even functions and classes), is good practice. > > That's not to say that some problems don't deserve a monolithic answer, > but if you're a beginner, i'd like to see you get into a modular habit. > > You can use the words script and program pretty much interchangeably. > in some contexts, each has additional connotations. For example, > somebody used to a compiled language may refer to a python source file > as a script, implying it's not as sophisticated as his own product. > But, closer to home, we usually refer to the file you directly pass to > the interpreter as a script, and any added files that get imported, as > modules, or libraries. > > Other times, people will refer to a simple program as a script, implying > that all it does is invoke some standard library functions, or even run > some external programs. But when it gets more complex, it gradually > turns into a "real program." > > > Why break up a monolith? > > Several reasons. If you factor the code into independent functions, and > give them good names, then each piece of the program is easier to > understand. You will especially appreciate that if you come back to the > code after doing something else for two weeks. Similarly if somebody > else has to take over your code, or maybe adapt it to a slightly > different purpose. > > Next, if it doesn't quite work, you can exercise the individual pieces > independently, and narrow down the problem more quickly. > > Next, if the progfram is slow, usually you can narrow it down to a few > key functions that take most of the time. You can write two versions of > the same function, and do some careful timings to decide which one to > use. > > Next, some of those functions may be useful in the next program you > write. If you "reuse" the code by copy & paste, and find a problem in > the new one, it's quite possible that the same problem may exist in your > first program. it's easier to bring those changes back if they're in a > function than if they're in lines 14 through 71. > > Finally, some of that reusable code may be worth moving to an external > file, called a module. Then the same copy can be literally shared > between multiple projects. This is how libraries were born, and you can > write your own, eventually. > > there are many other reasons, but some of them might not make sense to > you yet. > > > How do you break it up? > > First, separate the classic parts that most scripts will have. Put the > imports at the top, along with a comment describing the whole progfram's > purpose. Next put the global variables, which should be few. If there > are any constants, use all UPPERCASE for their names. > > Next, put the function and class definitions. Notice that none of them > will be called yet, so the order of execution isn't important to the > compiler. Each function needs a name, and you should use a name that > makes sense to you. Try to write functions that work at a single level > of complexity, and do one complete operation. Try not to do > input/output in the same functions that do the computation. > > And finally, put the actual mainline. It could be as simple as a call > to main(), but it may make more sense to you to put the calls to > argument processing here, rather than in a main function. By arguments > here, i'm referring to the stuff you typed on the command line when youi > invoked the script. This part of the code is where you do the magic > incantation: > > if __name__ == "__main__": > main() > > > > When the number of functions gets unwieldy, it's time to move some of >
Total newbie question: Best practice
Hi, I am just starting to learn Python (I have been at it only a few hours), so please bear with me. I have a few very small scripts (do you call them scripts or programs?) which work properly, and produce the results intended. However, they are monolithic in nature; i.e. they begin at the beginning and finish at the end. Having done a little reading, I note that it seems to be quite common to have a function main() at the start (which in turn calls other functions as appropriate), and then to call main() to do the work. Is that standard best practice? Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:
> On Nov 26, 1:53 pm, Rick Johnson wrote:
>> On Nov 20, 6:46 pm, Travis Parks wrote:
>>
>> > Hello:
>>
>> > I am currently working on designing a new programming language. It is
>> > a compiled language, but I still want to use Python as a reference.
>> > Python has a lot of similarities to my language, such as indentation
>> > for code blocks,
>>
>> I hope you meant to say "*forced* indention for code blocks"! "Forced"
>> being the key word here. What about tabs over spaces, have you decided
>> the worth of one over the other or are you going to repeat Guido's
>> folly?
>>
>> And please, i love Python, but the language is a bit asymmetrical. Do
>> try to bring some symmetry to this new language. You can learn a lot
>> from GvR's triumphs, however, you can learn even more from his follys.
>
> Personally, I find a lot of good things in Python. I thinking tabs are
> out-of-date. Even the MAKE community wishes that the need for tabs would
> go away and many implementations have done just that. I have been
> seriously debating about whether to force a specific number of spaces,
> such as the classic 4, but I am not sure yet. Some times, 2 or even 8
> spaces is appropriate (although I'm not sure when).
>
> I have always found the standard library for Python to be disjoint. That
> can be really beneficial where it keeps the learning curve down and the
> size of the standard modules down. At the same time, it means
> re-learning whenever you use a new module.
>
> My language combines generators and collection initializers, instead of
> creating a whole new syntax for comprehensions.
>
> [| for i in 0..10: for j in 0.10: yield return i * j |]
>
> Lambdas and functions are the same thing in my language, so no need for
> a special keyword. I also distinguish between initialization and
> assignment via the let keyword. Also, non-locals do not need to be
> defined explicitly, since the scoping rules in Unit are far more "anal".
>
> In reality though, it takes a certain level of arrogance to assume that
> any language will turn out without bumps. It is like I was told in
> college long ago, "Only the smallest programs are bug free." I think the
> same thing could be said for a language. The only language without flaws
> would be so small that it would be useless.
>
> I love these types of discussions though, because it helps me to be
> aware. When designing a language, it is extremely helpful to hear what
> language features have led to problems. For instance, C#'s foreach loops
> internally reuse a variable, which translates to something like this:
>
> using (IEnumerator enumerator = enumerable.GetEnumerator())
> {
> T current;
> while (enumerator.MoveNext())
> {
> current = enumerator.Current;
> // inner loop code goes here
> }
> }
>
> Since the same variable is reused, threads referencing the loop variable
> work against whatever value is currently in the variable, rather than
> the value when the thread was created. Most of the time, this means
> every thread works against the same value, which isn't the expected
> outcome. Moving the variable inside the loop _may_ help, but it would
> probably be optimized back out of the loop by the compiler. With the
> growth of threaded applications, these types of stack-based
> optimizations may come to an end. That is why it is important for a
> next-gen language to have a smarter stack - one that is context
> sensitive. In Unit, the stack grows and shrinks like a dynamic array, at
> each scope, rather than at the beginning and end of each function. Sure,
> there's a slight cost in performance, but a boost in consistency. If a
> programmer really wants the performance, they can move the variable out
> of the loop themselves.
>
> In fact, there are a lot of features in Unit that will come with
> overhead, such as default arguments, non-locals, function-objects, etc.
> However, the game plan is to avoid the overhead if it isn't used. Some
> things, such as exception handling, will be hard to provide without
> overhead. My belief is that, provided a tool, most developers will use
> it and accept the slight runtime overhead.
>
> I think everyone has an idea about what would make for the perfect
> language. I am always willing to entertain ideas. I have pulled from
> many sources: C#, Java, Python, JavaScript, F#, Lisp and more. The hope
> is to provide as much expression with as much consistency as possible.
> Just the other day I spent 2 hours trying to determine how to create a
> null pointer (yeah, it took that long).
>
> let pi = null as shared * Integer32 # null is always a pointer
>
> Originally, I wanted 'as' to be a safe conversion. However, I decided to
> make use of the 'try' keyword to mean a safe conversion.
>
> let nd = try base as shared * Derived let d = if nd.Succeeded: nd.Value
> else: null # or, shorthand let i = try Integer32.Parse("123") else 0
>
> Of cour
