Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74630 > unrolled thread

I need an idea for practise!

Back to article view | Back to comp.lang.python

Contents

  I need an idea for practise! Nicholas Cannon <nicholascannon1@gmail.com> - 2014-07-17 02:59 -0700
    Re: I need an idea for practise! alister <alister.nospam.ware@ntlworld.com> - 2014-07-17 10:13 +0000
    Re: I need an idea for practise! Abhiram R <abhi.darkness@gmail.com> - 2014-07-17 19:03 +0530
    Re: I need an idea for practise! Chris Angelico <rosuav@gmail.com> - 2014-07-18 00:20 +1000
    Re: I need an idea for practise! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 09:34 -0700
      Re: I need an idea for practise! Chris Angelico <rosuav@gmail.com> - 2014-07-18 03:20 +1000
        Re: I need an idea for practise! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 12:30 -0700
          Re: I need an idea for practise! Paul McNett <paul@mcnettware.com> - 2014-07-17 13:21 -0700
          Re: I need an idea for practise! Chris Angelico <rosuav@gmail.com> - 2014-07-18 12:03 +1000
            Re: I need an idea for practise! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 20:07 -0700
              Re: I need an idea for practise! Chris Angelico <rosuav@gmail.com> - 2014-07-18 13:23 +1000
                Re: I need an idea for practise! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 21:06 -0700
                  Re: I need an idea for practise! Chris Angelico <rosuav@gmail.com> - 2014-07-18 16:00 +1000
      Re: I need an idea for practise! Terry Reedy <tjreedy@udel.edu> - 2014-07-17 17:46 -0400
      Re: I need an idea for practise! Chris Angelico <rosuav@gmail.com> - 2014-07-18 12:04 +1000
    Re: I need an idea for practise! Orochi <kartikjagdale11@gmail.com> - 2014-07-17 11:05 -0700
      Re: I need an idea for practise! AudreyJean <iamAudreyJean@gmail.com> - 2014-07-18 08:42 -0700
    Re: I need an idea for practise! Nicholas Cannon <nicholascannon1@gmail.com> - 2014-07-17 19:03 -0700

#74630 — I need an idea for practise!

Ok I would say I am almost a intermediate python programer. I have made 2 programs(with GUI). And basically they are quite boring(a text editor and calculator). I love programming but i am lost of ideas i actually suck at finding good creative ideas. Now i am not looking to use these ideas make them and then try get money for it. I am only a kid and would love some like real world project ideas to learn more about python. Yeah so if any one would like to give me some ideas to train my self on that would be so cool!

[toc] | [next] | [standalone]

#74633

On Thu, 17 Jul 2014 02:59:11 -0700, Nicholas Cannon wrote:

> Ok I would say I am almost a intermediate python programer. I have made
> 2 programs(with GUI). And basically they are quite boring(a text editor
> and calculator). I love programming but i am lost of ideas i actually
> suck at finding good creative ideas. Now i am not looking to use these
> ideas make them and then try get money for it. I am only a kid and would
> love some like real world project ideas to learn more about python. Yeah
> so if any one would like to give me some ideas to train my self on that
> would be so cool!

How about creating an app. that interfaces with google groups so that it 
automatically cleans up the mess it makes before posting ;-) 
(single line paragraphs & double spacing )

heck i don't use google groups but would happily pay others to use such 
an app (not much though i am no Mark Shuttleworth)


-- 
Make it myself?  But I'm a physical organic chemist!

[toc] | [prev] | [next] | [standalone]

#74638

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jul 17, 2014 at 3:29 PM, Nicholas Cannon <nicholascannon1@gmail.com>
wrote:

 I have made 2 programs(with GUI). And basically they are quite boring(a
> text editor and calculator).
> --
> https://mail.python.org/mailman/listinfo/python-list
>


​What library did you use for the GUI?​

-- 
Abhiram.R

[toc] | [prev] | [next] | [standalone]

#74640

On Thu, Jul 17, 2014 at 7:59 PM, Nicholas Cannon
<nicholascannon1@gmail.com> wrote:
> I have made 2 programs(with GUI). And basically they are quite boring(a text editor and calculator).

Just for reference, those may be simple concepts, but they're anything
but boring. Most of us use text editors all the time, and I have a
habit of incorporating calculators into basically everything I write
(if it has a command-line input system of any kind). It's worth
knowing how to write both programs, because some day you'll be doing
something where you want the program to just quickly pop up a little
editor and let you change something on the fly, or just quickly fire
up a calculator that drops the result into some part of the program's
core functionality. It can be EXTREMELY handy, and useful.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74649

On Thursday, July 17, 2014 4:59:11 AM UTC-5, Nicholas Cannon wrote:
> Ok I would say I am almost a intermediate python
> programer. I have made 2 programs(with GUI). And basically
> they are quite boring(a text editor and calculator). I
> love programming but i am lost of ideas i actually suck at
> finding good creative ideas. Now i am not looking to use
> these ideas make them and then try get money for it. I am
> only a kid and would love some like real world project
> ideas to learn more about python. Yeah so if any one would
> like to give me some ideas to train my self on that would
> be so cool!

Hmm, unfortunately, if you do not already posses strong
imaginative and creative skills, you "may" never become
proficient at writing code, although your post does indicate
a "deep desire" to write code, so maybe there is yet hope!

First of all, you failed to explain the *extent* of the two
GUI applications you wrote, and as such, i do not know where
to start with my suggestions, so i will be forced to assume
that both of these apps are very "simplistic".

If the text editor is simply an app that allows: opening raw
text files, editing them, and then saving the changes, you
have a *whole* universe of functionality you could add to
that.

  How about writing a colorizer for source code, and why
  stop with *only* a Python colorizer? You can learn about
  regexs by doing this, AND about other languages also.
    
  How about source code analyzers or debuggers, or smart
  indent/dedent features and such...
    
  How about any number of text editing tools that an average
  user would want: like wrapping tools, searching and
  replacing tools, etc...
  
  Heck, how about extending a raw text editor to handle
  rich text!
  
Look, i know software already exists for all these
functionalities, however, in order to learn you must re-
invent the wheel, because you must know what is going on
"under the hood" if you expect to become proficient at
anything.

When someone wants to learn, say, the piano, they do not
just sit down and start hammering out Rachmaninoffs "prelude in
g minor" with the "key-chord-Staccatissimo-precision" of a
classically trained concert pianist, NO, they start out with
simple little pieces, and gradually work up towards more
difficult pieces, building a wealth of knowledge along the
way.

If your intention is to skip over the "little pieces" and go
strait to the "masterpieces", then you are doomed to failure
and might as well go watch a football game or join one of
the political parties, this is where the feeble minded
people aggregate to perpetuate their lack of intelligence!

The *true* student of any discipline will *relish* each and
every opportunity (no matter how miniscule) to learn
something new, because, it is the vast database of "little
ideas" which the masters *PILLAGE*, and then forge together
within the "roid-raging" fires of *PASSION*, the greatest
*MASTERPIECES* of human ingenuity that this decrepit lot of
human *FILTH* hardly deserves!

[toc] | [prev] | [next] | [standalone]

#74650

On Fri, Jul 18, 2014 at 2:34 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> If the text editor is simply an app that allows: opening raw
> text files, editing them, and then saving the changes, you
> have a *whole* universe of functionality you could add to
> that.
>
>   How about writing a colorizer for source code, and why
>   stop with *only* a Python colorizer? You can learn about
>   regexs by doing this, AND about other languages also.
>
>   How about source code analyzers or debuggers, or smart
>   indent/dedent features and such...
>
>   How about any number of text editing tools that an average
>   user would want: like wrapping tools, searching and
>   replacing tools, etc...
>
>   Heck, how about extending a raw text editor to handle
>   rich text!

To the OP: Ranting Rick's words shouldn't be taken to heart, although
it's plenty possible to learn from him.

My recommendation is: Scratch your own itch. Don't add features for
the sake of adding features - that's a recipe for useless piles of
mess. Instead, add exactly the feature that you need right now (even
if adding that feature means it's no longer "right now" when you get a
chance to use it), and then you know it's being useful. For instance,
I have a mini-editor built into my MUD client [1] which is inferior to
most decent code editors, but it has a few special features that make
it useful *to me* and *in specific circumstances*; for most of my real
work, I still use SciTE, because it's a much better editor. But the
pop-out editor lets me:

* Work with my server via a TELNET-like connection, and simply pop up an editor
* Send the contents of the edit box back to the server. Since the
server controls what's edited, it'll begin with an appropriate command
that says "Hey server, here's that file I was editing".
* Place the initial cursor position, again under server control -
handy when I pop up a "git commit" message editor
* Explicitly hard-wrap text to a specific column width, or auto-wrap on send
* Integrate editing of text into any server-side command - it might
not be a file that's being edited

All this makes it distinctly superior to either ssh'ing to the server
and editing a file (possible only for actual files, possible only for
people with ssh logins to the server, etc, etc, etc), or explicitly
copying and pasting to another editor window (much easier to let the
program do it). And since it's a feature I use on a regular basis,
there's a guarantee that it's actually useful, and therefore will be
developed as it has need. In contrast, features that I added to a
program only because someone said they'd use it (and then probably
never even used it themselves) tend to languish, left as an artifact
of a previous era rather than constantly improved.

By the way, one specific point about RR's advice: A colorizer should
*not* be written using regexps. It'd make for an absolute nightmare of
impossible-to-debug regexp strings, plus there are fundamental
limitations on what you can accomplish with them. You need to use a
lexer - a lexical analyzer. Basically, to correctly colorize code, you
need to have something equivalent to the first part of the language
interpreter, but with a lot more tolerance for errors. That's a pretty
big thing to write as regexps.

ChrisA


[1] Code here: https://github.com/Rosuav/Gypsum/blob/master/plugins/editor.pike

[toc] | [prev] | [next] | [standalone]

#74681

On Thursday, July 17, 2014 12:20:13 PM UTC-5, Chris Angelico wrote:
> By the way, one specific point about RR's advice: A
> colorizer should *not* be written using regexps. It'd make
> for an absolute nightmare of impossible-to-debug regexp
> strings

Just because *YOU* harbor irrational fears of regexp pattern
syntax, does mean the rest of us should propagate your
religious beliefs and worship your "shrines of
fear-mongering".

  Q: Is using regexps to create a colorizer the *ONLY* method
  to create a colorizer?  
  
  A: Uh, no!
  
  Q: Is using regexps the *BEST* method to create a
  colorizer?
  
  A: Depends on who you ask and what the specific details
  are.

Remember, this is "academic exercise", and i believe a damn
*good* exercise because *even* a noob can understand the basic
problems that need to be solved to create a colorizer:

  1. I have a finite set of keywords and lexical structures
  that need to be located within a text.
  
  2. I need to map colors to patterns so i can paint the
  keywords and lexical structures appropriately when i find
  them.
  
  3. I need to institute events that will cause the
  colorizer to search for the patterns at appropriate times
 (for instance: when text is loaded, when text is edited, etc)
      
  3a. Furthermore, i need to refine the breadth of my search
  area depending on the current context of the edit --
  Should i search *only* the current line being edited, or,
  is the editing occurring inside a larger "multi-line
  lexical structure" that will need to be considered, OR,
  should i search the entire text???

> plus there are fundamental limitations on what you can
> accomplish with them.

Of course, *REMEMBER*, this is an "academic exercise", 
intended to familiarize the student with regexps and doing
so in the context of a *real* world problem, who's scope is
within the grasp of a noob, not some rechid flatulence pulled
from the anus of a "so-called" teacher.

But don't tell me for a *SECOND* that a colorizer, and a
damn good one, can not be written utilizing regexps, because
you're either wrong, or you're scared, or you're ignorant,
or you're all of the above!

> You need to use a lexer - a lexical analyzer. Basically,
> to correctly colorize code, you need to have something
> equivalent to the first part of the language interpreter,
> but with a lot more tolerance for errors. That's a pretty
> big thing to write as regexps.

Great Chris, so as a "lesson" for learning *regexps* you
propose that your students write a *lexer* instead. What's
next? Do you propose they drive an auto whilst protruding
their head from the vehicle like a canine, and observing the
plant life on the side of the road to earn a degree in
botany?

You know, you would fit in nicely in the American public
school system, since American teachers are not only free of
the requirement of "teaching", they are actually *COMPELLED*
not to do so by the greedy unions.

    I SURMISE YOUR DESK WILL BE DEVOID OF ANY "TREE BEARING" FRUITS!

[toc] | [prev] | [next] | [standalone]

#74703

On 7/17/14, 12:30 PM, Rick Johnson wrote:
> You know, you would fit in nicely in the American public
> school system, since American teachers are not only free of
> the requirement of "teaching", they are actually*COMPELLED*
> not to do so by the greedy unions.

Hi Rick,

I know a lot of American public school teachers, and they are among the 
hardest-working people I've ever encountered. I have no clue what you 
mean about them being free of the requirement to teach.

Do you find that insulting people achieves your goals?

Paul

[toc] | [prev] | [next] | [standalone]

#74709

On Fri, Jul 18, 2014 at 5:30 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> But don't tell me for a *SECOND* that a colorizer, and a
> damn good one, can not be written utilizing regexps, because
> you're either wrong, or you're scared, or you're ignorant,
> or you're all of the above!

It might well be able to *utilize* regexps (as Terry showed, the one
in idlelib apparently does use them), but very few modern programming
languages can be fully and correctly defined within the limits of
regexp syntax. For instance, how can you recognize and thus colorize
assignments differently from name references, to distinguish between
"foo = 1" and "foo == 1"? Can you do that with a regexp? And there's
plenty more syntax that's tricky to define.

I might be wrong, and I might be ignorant, but I'm not scared. I know
what a regular expression can and can't do, and it's not fear to avoid
using them for jobs they can't do.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74718

On Thursday, July 17, 2014 9:03:40 PM UTC-5, Chris Angelico wrote:
> [colorizers] might well be able to *utilize* regexps [...]
> but very few modern programming languages can be fully and
> correctly defined within the limits of regexp syntax.

We're not talking about "defining" or "interpreting"
languages Chris, we're simply talking about "colorizers" --
which simply search for lexical patterns and apply *COLOR*
to the resulting matches!
    
    PAY ATTENTION!
 
> For instance, how can you recognize and thus colorize
> assignments differently from name references, to
> distinguish between "foo = 1" and "foo == 1"?

First of all, why the heck would want to colorize something
like that? And if your intention is "highlight" cases where a
programmer uses "==" in a condition, then you need to use a
"source code analyzer", like Pylint!

Secondly, as the number of colorizer targets increases, the
effectiveness of colored text decreases -- from a "human
comprehension" perspective that is. For me, only the
following targets need colorizing:

      Keywords
      Built-ins
      Terminated Strings
      Un-terminated Strings
      Comments
      Annotations
      
That's it! Anymore color and your code starts to resemble a
Pollock drip painting.

Now, finally, if you cannot write a regexp that matches:

  1. One or more alphanumeric chars(or the US) followed by
  zero or more spaces followed by two equals chars followed
  by zero or more spaces followed by one or more alphanumeric
  chars(or the US)
      
or
    
  2. One or more alphanumeric_chars(or the US) followed by
  zero or more spaces followed by one equals char followed
  by zero or more spaces, followed by one or more
  alphanumeric chars(or the US)
  
    
Then you are either joking or trolling or you need to read
the Python re docs.

    https://docs.python.org/2/library/re.html#module-re

[toc] | [prev] | [next] | [standalone]

#74719

On Fri, Jul 18, 2014 at 1:07 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> For me, only the following targets need colorizing:
>
>       Keywords
>       Built-ins

And be sure *not* to colorize built-ins (but *do* colorize keywords)
in contexts where the tokens are actually identifiers, like "x.open =
1". Plus, if you want this to be truly general, you need to have it
understand that some keywords aren't keywords if the shebang is
different, although with 2.7 vs 3.4 that only really applies to
nonlocal (if True/False/None are colored as keywords even though
they're technically builtins, that's not a big deal); if you want to
support Python 2.5, you'd also have to cope with a __future__
directive adding a keyword, but that's quite optional.

It's not as simple as you might think. I've worked with plenty of
syntax highlighters that get something wrong in some context, and it's
extremely annoying; in some cases it makes the colorization actually
harmful, rather than helpful. And it's absolutely *essential* that the
lexer and the language agree on, for instance, what characters
constitute identifiers; if I have a partially non-ASCII variable name
and only the ASCII half of it gets highlighted, that can be highly
distracting.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74723

On Thursday, July 17, 2014 10:23:50 PM UTC-5, Chris Angelico wrote:
> And be sure *not* to colorize built-ins (but *do* colorize
> keywords) in contexts where the tokens are actually
> identifiers, like "x.open = 1".

Just check for word boundaries on all your keywords and 
built-ins and you're *DONE*!

> Plus, if you want this to be truly general, you need to
> have it understand that some keywords aren't keywords if
> the shebang is different, although with 2.7 vs 3.4 that
> only really applies to nonlocal (if True/False/None are
> colored as keywords even though they're technically
> builtins, that's not a big deal); if you want to support
> Python 2.5, you'd also have to cope with a __future__
> directive adding a keyword, but that's quite optional.
> It's not as simple as you might think.

Stop it, you're embarrassing yourself with all this rambling!

You should have shut up a long time ago. Just like the
thread where you embarrassed yourself with your limited
knowledge of IDLE[1] and Tkinter, you're now really loosing
all respect as a competent programmer if you cannot even
write these "simple" regexps.

> I've worked with plenty of syntax highlighters that get
> something wrong in some context, and it's extremely
> annoying; in some cases it makes the colorization actually
> harmful, rather than helpful. And it's absolutely
> *essential* that the lexer and the language agree on, for
> instance, what characters constitute identifiers; if I
> have a partially non-ASCII variable name and only the
> ASCII half of it gets highlighted, that can be highly
> distracting.

Oh i get it now, your confusing Python with REXX again...

    *face palm*
    
[1] Heck, you don't even realize that IDLE and an "acronym".

[toc] | [prev] | [next] | [standalone]

#74728

On Fri, Jul 18, 2014 at 2:06 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Thursday, July 17, 2014 10:23:50 PM UTC-5, Chris Angelico wrote:
>> And be sure *not* to colorize built-ins (but *do* colorize
>> keywords) in contexts where the tokens are actually
>> identifiers, like "x.open = 1".
>
> Just check for word boundaries on all your keywords and
> built-ins and you're *DONE*!

Of course, because (True.real) is just as much not-a-keyword as
(real.True), naturally.

>> Plus, if you want this to be truly general, you need to
>> have it understand that some keywords aren't keywords if
>> the shebang is different, although with 2.7 vs 3.4 that
>> only really applies to nonlocal (if True/False/None are
>> colored as keywords even though they're technically
>> builtins, that's not a big deal); if you want to support
>> Python 2.5, you'd also have to cope with a __future__
>> directive adding a keyword, but that's quite optional.
>> It's not as simple as you might think.
>
> Stop it, you're embarrassing yourself with all this rambling!
>
> You should have shut up a long time ago. Just like the
> thread where you embarrassed yourself with your limited
> knowledge of IDLE[1] and Tkinter, you're now really loosing
> all respect as a competent programmer if you cannot even
> write these "simple" regexps.

Simple regexps that differ in one tiny part based on something way
earlier? Sure, they're simple in the sense that you can devolve them
into very simple components. By the same token, all Python programs
are simple, because there are only 101 opcodes. Doesn't make it
readable.

>> I've worked with plenty of syntax highlighters that get
>> something wrong in some context, and it's extremely
>> annoying; in some cases it makes the colorization actually
>> harmful, rather than helpful. And it's absolutely
>> *essential* that the lexer and the language agree on, for
>> instance, what characters constitute identifiers; if I
>> have a partially non-ASCII variable name and only the
>> ASCII half of it gets highlighted, that can be highly
>> distracting.
>
> Oh i get it now, your confusing Python with REXX again...
>
>     *face palm*

I am? Oh right, because REXX totally has non-ASCII variable names, and
because I was always using syntax highlighting back in the 90s, but I
don't do it now. Of course.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74693

On 7/17/2014 1:20 PM, Chris Angelico wrote:

> By the way, one specific point about RR's advice: A colorizer should
> *not* be written using regexps. It'd make for an absolute nightmare of
> impossible-to-debug regexp strings, plus there are fundamental
> limitations on what you can accomplish with them. You need to use a
> lexer - a lexical analyzer. Basically, to correctly colorize code, you
> need to have something equivalent to the first part of the language
> interpreter, but with a lot more tolerance for errors. That's a pretty
> big thing to write as regexps.

It depends on how deeply one wants to colorize. idlelib.ColorDelegator 
colors comments, strings, keywords, builtin names, and names following 
'def' and 'class' with the following regexes.

def any(name, alternates):
     "Return a named group pattern matching list of alternates."
     return "(?P<%s>" % name + "|".join(alternates) + ")"

def make_pat():
     kw = r"\b" + any("KEYWORD", keyword.kwlist) + r"\b"
     builtinlist = [str(name) for name in dir(builtins)
                                         if not name.startswith('_') and \
                                         name not in keyword.kwlist]
     # self.file = open("file") :
     # 1st 'file' colorized normal, 2nd as builtin, 3rd as string
     builtin = r"([^.'\"\\#]\b|^)" + any("BUILTIN", builtinlist) + r"\b"
     comment = any("COMMENT", [r"#[^\n]*"])
     stringprefix = r"(\br|u|ur|R|U|UR|Ur|uR|b|B|br|Br|bR|BR|rb|rB|Rb|RB)?"
     sqstring = stringprefix + r"'[^'\\\n]*(\\.[^'\\\n]*)*'?"
     dqstring = stringprefix + r'"[^"\\\n]*(\\.[^"\\\n]*)*"?'
     sq3string = stringprefix + r"'''[^'\\]*((\\.|'(?!''))[^'\\]*)*(''')?"
     dq3string = stringprefix + r'"""[^"\\]*((\\.|"(?!""))[^"\\]*)*(""")?'
     string = any("STRING", [sq3string, dq3string, sqstring, dqstring])
     return kw + "|" + builtin + "|" + comment + "|" + string +\
            "|" + any("SYNC", [r"\n"])

prog = re.compile(make_pat(), re.S)
idrog = re.compile(r"\s+(\w+)", re.S)
asprog = re.compile(r".*?\b(as)\b")

I am not sure if the separate definition for as is still needed, or is a 
holdover from when 'as' was not a keyword except in certain contexts.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#74710

On Fri, Jul 18, 2014 at 7:46 AM, Terry Reedy <tjreedy@udel.edu> wrote:
>     # self.file = open("file") :
>     # 1st 'file' colorized normal, 2nd as builtin, 3rd as string

Is this pair of comments a hold-over from when it was common to use
the file() constructor? Looks like it got searched-and-replaced.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74660

Brother,I had same views and after creating some small projects I directly tried to jump over large projects (went for data mining using neural network) and FAILED.
I realized small things really matter.
So I suggest just couple of GUI projects are not enough go for more.
start with anything.
here are couple of links I am staring with:
1. http://www.reddit.com/r/beginnerprojects
2. http://www.openbookproject.net/py4fun/

and there are many more you can go for "learnstreet.com"

I am too a Intermediate but I prefer to say Beginner and if you want we can make projects together.
I am Currently working on a small chat application.

[toc] | [prev] | [next] | [standalone]

#74753

On 07/17/2014 11:05 AM, Orochi wrote:
>
>
> and there are many more you can go for "learnstreet.com"
>
>
FYI: Learnstreet sent out an email a few weeks ago saying that they are 
shutting down.  Here is a link I found about it.
https://news.ycombinator.com/item?id=7986979

-- 
Deb in WA, USA

[toc] | [prev] | [next] | [standalone]

#74708

When I say i suck at finding good creative ideas I dont mean like I can think of  anything its more like i cant think of anything that is within my scope of skill. These ideas are great guys thanks. Also the gui tool kit i used for the apps is tkinter because i am reading a book about python and it covers that tool kit. Also i like this idea of ssh'ing to a server where i could have a python program that allows files to be uploaded to a database and brought down from the data base. I am just not so good with the hardware so I dont really now how to create one. Also I wouldnt mind putting more functionality into my programs and stuff that sounds alright and also re inventing the wheel sounds like good practise.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web