Re: Suggesion for an undergrad final year project in Python
On Tue, 01 Feb 2005 12:11:47 +, Kartic wrote: > Sridhar said the following on 2/1/2005 2:11 AM: >> Hi, >> >> I am doing my undergrade CS course. I am in the final year, and would >> like to do my project involving Python. Our instructors require the >> project to have novel ideas. Can the c.l.p people shed light on this >> topic? > > You try and implement some CS concepts you have learnt using Python. For > example, if you had a course on parsing and compiler design, try to > implement a simple language in Python. Could I suggest going for an area that particularly interests you ; rather than saying "what sort of project " come up with an area of interest - this'll mean you probably have more knowledge and will put in more effort - and then ask for ideas - ideally about something that is missing. -- http://mail.python.org/mailman/listinfo/python-list
Re: The use of :
On Mon, 29 Nov 2004 01:12:16 -0500, Jeremy Bowers wrote: > The only punctuation you *need* is whitespace. See Forth (I don't know > if this is perfect but I'd bet the transform is simple), : Announce ." Forth has a fair bit of punctuation" ; -- http://mail.python.org/mailman/listinfo/python-list
Re: wxStyledTextCtrl problem ?
On Sun, 28 Nov 2004 23:43:32 -0800, Josiah Carlson wrote: > I don't know why the problem you are having happens, but I would just > make a call to self.Editor.SetFocus() on an EVT_ACTIVATE event. Tried that, it doesn't work :( Or to be precise, it works every other time :) -- http://mail.python.org/mailman/listinfo/python-list
Re: wxStyledTextCtrl problem ?
On Mon, 29 Nov 2004 08:10:18 +, Jean Brouwers wrote: > If you are running GTK+ try using > > self.Editor.SetSTCFocus(True) > > in addition to or instead of SetFocus(). Plus maybe > > wx.CallAfter(self.Editor.EnsureCaretVisible) > > It solved the 'dissapearing caret' problem for our application. Thanks - that worked perfectly ! -- http://mail.python.org/mailman/listinfo/python-list
Re: weird behaviour of "0 in [] is False"
Sylvain Thenault wrote: l = [] 0 in (l is False) (l is False) is not a tuple or list, it's a boolean value. > Traceback (most recent call last): > File "", line 1, in ? > TypeError: iterable argument required (0 in l) is False > True 0 in l is False becuase l is empty, so it's False is False which is true, (except in Intercal probably and Visual C++) 0 in l is False > False l is False is False because l is not the value false though it has a false value (err.) Okay. l != False because it's not the displayed value false but if not l would evaluated to true because [] is a false equivalent. 0 in False okay this should be an error . something to do with the equivalence confusion of what False is ? -- http://mail.python.org/mailman/listinfo/python-list
Re: weird behaviour of "0 in [] is False"
John Roth wrote: > It's not an error. As one of the first responders said, check > the language definition. That defines both 'in' and 'is' > as equality operators, and defines exactly what a chain > of equality operators means. > > In this case, it means: > > (0 in l) and (l is False) > > The and short circuits, giving the result of False without > ever doing the final comparison. > > Granted, that's not exactly obvious... Thanks ; you learn something every day :) -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
On Mon, 13 Dec 2004 19:33:25 -0800, projecktzero wrote: > A co-worker considers himself "old school" in that he hasn't seen the > light of OOP.(It might be because he's in love with Perl...but that's > another story.) He thinks that OOP has more overhead and is slower than > programs written the procedural way. I poked around google, but I don't > know the magic words to put in to prove or disprove his assertion. Can > anyone point me toward some resources? Oh, he's probably telling the truth, in that unless you have the type of an object defined at run time then a straight procedural call is going to be quicker, because classic "procedural" code has a very tight mapping to the underlying hardware. Of course, the issue is not about raw speed - which in many cases does not matter (and the few where it does you can work around) ; it's about maintainability, modularity and so on. I once worked at a place (this would be mid 1980s) where the other coders would not accept that it was "better" to use names for subroutines such as CalculateBillingTotal or variables such as StaffName. The argument was "well, gosub 13000 and S$ are the same thing" which misses the point. If he's that obsessed speed what is he doing coding with Perl (hell I like Perl) which is compiled to a bytecode which is then interpreted why not code in 'C' or even Assembler, then it'll be really quick ? Answer ; you like the facilities of the language. So it is a trade off. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tutorial problem
On Mon, 27 Dec 2004 08:15:51 -0800, Rÿe9veillÿe9 wrote:
> The problem is that it doesnt print the
>
> [ choice = input ('Pick a number:') ]
>
> command. It just runs thru the whole thing without
> allowing the user a selection.
Are you running it from the command line ? Some editors do not 'work'
properly with command line input (redirection issues).
--
http://mail.python.org/mailman/listinfo/python-list
