>I found Python3's sqlite3 library. I found that I needed sql commands for using it. > >I have tried sql.learncodethehardway but it isn't complete yet. I tired looking on stackoverflow's sql tag also but nothing much there.
There is some useful references in the Python's documents. If you want to connect to the mysql, you should import the packages related. On Tue, Aug 6, 2013 at 10:11 PM, <python-list-requ...@python.org> wrote: > Send Python-list mailing list submissions to > python-list@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-list > or, via email, send a message with subject or body 'help' to > python-list-requ...@python.org > > You can reach the person managing the list at > python-list-ow...@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-list digest..." > > Today's Topics: > > 1. Re: Can someone suggest better resources for learning > sqlite3? I wanted to use the Python library but I don't know > sql. > (Jordi Riera) > 2. Re: Sort lines in a plain text file alphanumerically > (Devyn Collier Johnson) > 3. Re: Sort lines in a plain text file alphanumerically > (Chris Angelico) > 4. Re: Newbie: static typing? (Burak Arslan) > 5. Re: Working with XML/XSD (Burak Arslan) > 6. Re: Newbie: static typing? (Antoon Pardon) > 7. Re: Class hierarchy problem (Chris Angelico) > 8. Re: Newbie: static typing? (Chris Angelico) > 9. Re: Newbie: static typing? (Eric S. Johansson) > > > ---------- Forwarded message ---------- > From: Jordi Riera <kender...@gmail.com> > To: Gilles <nos...@nospam.com> > Cc: python-list@python.org > Date: Tue, 6 Aug 2013 13:05:02 +0200 > Subject: Re: Can someone suggest better resources for learning sqlite3? I > wanted to use the Python library but I don't know sql. > Hey, > > can't you use django to deal with your sqlite? > If so, django > models<https://docs.djangoproject.com/en/dev/topics/db/models/>are a smart > way to do. > > Regards, > Jordi > > > On Tue, Aug 6, 2013 at 12:51 PM, Gilles <nos...@nospam.com> wrote: > >> On Sat, 3 Aug 2013 10:57:32 -0700 (PDT), Aseem Bansal >> <asmbans...@gmail.com> wrote: >> >I found Python3's sqlite3 library. I found that I needed sql commands >> for using it. >> > >> >I have tried sql.learncodethehardway but it isn't complete yet. I tired >> looking on stackoverflow's sql tag also but nothing much there. >> >> It'll be easier to read tutorials specifically meant to use Sqlite >> with Python: >> >> www.google.com/search?q=python+sqlite+examples >> -- >> http://mail.python.org/mailman/listinfo/python-list >> > > > > -- > - Jordi Riera, Connecting people. > +33 662217507 > > > ---------- Forwarded message ---------- > From: Devyn Collier Johnson <devyncjohn...@gmail.com> > To: Python Mailing List <python-list@python.org> > Cc: > Date: Tue, 06 Aug 2013 08:29:46 -0400 > Subject: Re: Sort lines in a plain text file alphanumerically > > On 08/06/2013 06:52 AM, Chris Angelico wrote: > >> On Tue, Aug 6, 2013 at 11:38 AM, Devyn Collier Johnson >> <devyncjohn...@gmail.com> wrote: >> >>> with open('/home/collier/pytest/**sort.TXT') as file: >>> sorted(file, key=str.casefold, reverse=True) >>> >>> >>> Thanks for the advice Joshua. I find these tips very useful. However, how >>> would I close the files, or would they close after the "with" construct >>> is >>> complete? >>> >> >> That's the whole point of 'with'. It calls open(), then calls >> __enter__, and it guarantees to call __exit__ before executing any >> code following the with block. With a file object, __exit__ will close >> the file. >> >> ChrisA >> > > Thanks! Now I see why using "with" is a better way to write the code. > > DCJ > > > > ---------- Forwarded message ---------- > From: Chris Angelico <ros...@gmail.com> > To: python-list@python.org > Cc: > Date: Tue, 6 Aug 2013 14:15:06 +0100 > Subject: Re: Sort lines in a plain text file alphanumerically > On Tue, Aug 6, 2013 at 12:44 PM, Joshua Landau <jos...@landau.ws> wrote: > > On 6 August 2013 11:52, Chris Angelico <ros...@gmail.com> wrote: > >> On Tue, Aug 6, 2013 at 11:38 AM, Devyn Collier Johnson > >> <devyncjohn...@gmail.com> wrote: > >>> with open('/home/collier/pytest/sort.TXT') as file: > >>> sorted(file, key=str.casefold, reverse=True) > >>> > >>> > >>> Thanks for the advice Joshua. I find these tips very useful. However, > how > >>> would I close the files, or would they close after the "with" > construct is > >>> complete? > >> > >> > >> That's the whole point of 'with'. It calls open(), > > > > To be pedantic, it does not. open is called by the time the with gets > involved. > > > > The entire statement does. Yes, it's not 'with' that does that, but it > is called. Anyway, that's detaily stuff :) > > ChrisA > > > > ---------- Forwarded message ---------- > From: Burak Arslan <burak.ars...@arskom.com.tr> > To: python-list@python.org > Cc: > Date: Tue, 06 Aug 2013 16:27:10 +0300 > Subject: Re: Newbie: static typing? > On 08/06/13 13:12, Rui Maciel wrote: > > Joshua Landau wrote: > > > >> What's the actual problem you're facing? Where do you feel that you > >> need to verify types? > > A standard case would be when there's a function which is designed > expecting > > that all operands support a specific interface or contain specific > > attributes. > > > > In other words, when passing an unsupported type causes problems. > > > > Hi, > > First, let's get over the fact that, with dynamic typing, code fails at > runtime. Irrespective of language, you just shouldn't ship untested > code, so I say that's not an argument against dynamic typing. > > This behaviour is only a problem when code fails *too late* into the > runtime -- i.e. when you don't see the offending value in the stack trace. > > For example, consider you append values to a list and the values in that > list get processed somewhere else. If your code fails because of an > invalid value, your stack trace is useless, because that value should > not be there in the first place. The code should fail when appending to > that list and not when processing it. > > The "too late" case is a bit tough to illustrate. This could be a rough > example: https://gist.github.com/plq/6163839 Imagine that the list there > is progressively constructed somewhere else in the code and later > processed by the sq_all function. As you can see, the stack trace is > pretty useless as we don't see how that value got there. > > In such cases, you do need manual type checking. > > Yet, as someone else noted, naively using isinstance() for type checking > breaks duck typing. So you should read up on abstract base classes: > http://docs.python.org/2/glossary.html#term-abstract-base-class > > These said, I've been writing Python for several years now, and I only > needed to resort to this technique only once. (i was working on a > compiler) Most of the time, you'll be just fine without any manual type > checking. > > Best regards, > Burak > > > > > > ---------- Forwarded message ---------- > From: Burak Arslan <burak.ars...@arskom.com.tr> > To: python-list@python.org > Cc: > Date: Tue, 06 Aug 2013 16:33:16 +0300 > Subject: Re: Working with XML/XSD > On 08/06/13 01:56, David Barroso wrote: > > Hello, > > I was wondering if someone could point me in the right direction. I > > would like to develop some scripts to manage Cisco routers and > > switches using XML. However, I am not sure where to start. Does > > someone have some experience working with XML, Schemas and things like > > that? Which libraries do you use? Do you know of any good tutorial? > > > > Hi, > > I develop Spyne (http://spyne.io), it does let you define Xml Schema > types, generate the Schema documents, (and in the upcoming release, > parse them) and also does both serialization and deserialization of > python objects from and to xml according to definitions in the xml > schema. It also does RPC :) > > In case you don't want to use a framework, use lxml, it's a very good > xml manipulation library based on libxml2/libxslt. You can use > lxml.objectify for xml serialization as well. > > Best, > Burak > > > > > ---------- Forwarded message ---------- > From: Antoon Pardon <antoon.par...@rece.vub.ac.be> > To: python-list@python.org > Cc: > Date: Tue, 06 Aug 2013 15:57:26 +0200 > Subject: Re: Newbie: static typing? > Op 06-08-13 15:27, Burak Arslan schreef: > > On 08/06/13 13:12, Rui Maciel wrote: > >> Joshua Landau wrote: > >> > >>> What's the actual problem you're facing? Where do you feel that you > >>> need to verify types? > >> A standard case would be when there's a function which is designed > expecting > >> that all operands support a specific interface or contain specific > >> attributes. > >> > >> In other words, when passing an unsupported type causes problems. > >> > > > > Hi, > > > > First, let's get over the fact that, with dynamic typing, code fails at > > runtime. Irrespective of language, you just shouldn't ship untested > > code, so I say that's not an argument against dynamic typing. > > Why not? Can ease of development not be a consideration? So if some > kind of faults are easier to detect at compile time if you have static > typing than if you have to design a test for them, I don't see why that > can't be an argument. > > -- > Antoon Pardon > > > > ---------- Forwarded message ---------- > From: Chris Angelico <ros...@gmail.com> > To: python-list@python.org > Cc: > Date: Tue, 6 Aug 2013 15:02:23 +0100 > Subject: Re: Class hierarchy problem > On Tue, Aug 6, 2013 at 2:58 PM, BrJohan <brjo...@gmail.com> wrote: > > On 06/08/2013 11:30, Chris Angelico wrote: > >> > >> On Tue, Aug 6, 2013 at 10:10 AM, BrJohan <brjo...@gmail.com> wrote: > >>> > >>> Now, I want to create instances of the correct subclasstype as decided > by > >>> the common baseclass, like this: > >>> > >>> i = Sup(args_allowing_the_baseclass_to_deduce_correct_subclass) > >>> > >>> where i can be of any class except Sup itself (as decided by Sup) > >> > >> > >> Can you do this as a factory function instead of the class itself? > >> Then all you need to do is call the appropriate class. > >> > >> ChrisA > >> > > > > My classhierarchy is like a multilevel tree where each non-leaf node > (class) > > is given knowledge about its nearest subclasses and their 'capacities'. > > > > So, my idea is to let the 'upper' class recursively choose which of its > > nearest subclasses is the 'correct' one, until approaching a 'leaf' class > > from which the instance should be created. And, given my knowledge that a > > solution along the lines of this idea has been designed and was working, > I'm > > still hopeful ... (or I'll have to investigate all those old backup-DVDs) > > [ responding on-list - I hope it was mere oversight that had this come > privately to me alone ] > > This is code smell; this recursive search for the "right" class seems > likely to be wrong. Can you have the classes perhaps register > themselves in some way? On what basis is a superclass to determine > that one of its subclasses should handle this request? > > ChrisA > > > > ---------- Forwarded message ---------- > From: Chris Angelico <ros...@gmail.com> > To: python-list@python.org > Cc: > Date: Tue, 6 Aug 2013 15:06:40 +0100 > Subject: Re: Newbie: static typing? > On Tue, Aug 6, 2013 at 2:57 PM, Antoon Pardon > <antoon.par...@rece.vub.ac.be> wrote: > > Op 06-08-13 15:27, Burak Arslan schreef: > >> On 08/06/13 13:12, Rui Maciel wrote: > >>> Joshua Landau wrote: > >>> > >>>> What's the actual problem you're facing? Where do you feel that you > >>>> need to verify types? > >>> A standard case would be when there's a function which is designed > expecting > >>> that all operands support a specific interface or contain specific > >>> attributes. > >>> > >>> In other words, when passing an unsupported type causes problems. > >>> > >> > >> Hi, > >> > >> First, let's get over the fact that, with dynamic typing, code fails at > >> runtime. Irrespective of language, you just shouldn't ship untested > >> code, so I say that's not an argument against dynamic typing. > > > > Why not? Can ease of development not be a consideration? So if some > > kind of faults are easier to detect at compile time if you have static > > typing than if you have to design a test for them, I don't see why that > > can't be an argument. > > Sure, which is why I like working in Pike, which does have static type > declarations (when you want them; they can get out the way when you > don't). But there will always be, regardless of your language, > criteria that static typing cannot adequately handle, so just write > your code to cope with exceptions - much easier. If the exception's > never thrown, the bug can't be all that serious; otherwise, just deal > with it when you find it, whether that be in initial testing or years > later in production. There WILL BE such errors - that's a given. Deal > with them, rather than trying to eliminate them. > > ChrisA > > > > ---------- Forwarded message ---------- > From: "Eric S. Johansson" <e...@harvee.org> > To: python-list@python.org, "Burak Arslan" <burak.ars...@arskom.com.tr> > Cc: > Date: Tue, 06 Aug 2013 09:58:53 -0400 > Subject: Re: Newbie: static typing? > On Tue, 06 Aug 2013 09:27:10 -0400, Burak Arslan < > burak.ars...@arskom.com.tr> wrote: > > First, let's get over the fact that, with dynamic typing, code fails at >> runtime. Irrespective of language, you just shouldn't ship untested >> code, so I say that's not an argument against dynamic typing. >> > > It's not so much shipping untested code as not having or unable to test > all the pathways in the code shipped. I ran into this problem with a server > I built. I ended up solving the problem by building a testing scaffolding > that let me control all inputs. It would've been much easier with static > typing to make sure all the pieces lined up. > > The other technique I've used is a properly set up exception handling > environment. Do it right and you can log all of the errors so that you have > useful information. Part of "doing it right" includes a system that tells > you when exceptions happened right away so the server doesn't run for days > or more failing at random but nobody notices because your exceptions keep > the system for failing completely. > > I guess this is a long way of saying instrument your software so that it > can be tested and or give you enough information about the internal state. > This is sort of like building a specialized integrated circuit. You need to > design it so it can be tested/observed after it's been embedded in epoxy > and not just count on being able to probe the wafer in the lab. > > > -- > http://mail.python.org/mailman/listinfo/python-list >
-- http://mail.python.org/mailman/listinfo/python-list
