Re: Python 3 vs Python 2.7 dilemma
I would recommend you going on the Python 2.x path. Python 2.x is far from being deprecated. According to Wesley Chun (active member of Python community and author of Core Python Programming) on a Google I/O talk, everybody will be using Python 3 by 2018, so there's still plenty of time. Besides, you can start with Python 2.7, which still is 2.x but introduces 3.x features, and in some benchmarks seems to be more efficient than latest 3.x. 3.x is said to be backwards incompatible, but that incompatibility is not something that would bring you a limitation on porting your code later. So, for the sake of web frameworks and runtime infrastructures, I'd stick to 2.x. This is my IMHO, I'm sure you can get a more accurate answer from someone in this list more experienced in the matter ;) Have a good one. On Tue, May 17, 2011 at 12:48 AM, Navkirat Singh wrote: > Hi Guys, > > I have been trying to fight this issue for sometime now. I know that a > large part of the python 3rd party software base has not been ported to > python 3 yet. I am trying to build a web-based enterprise solution for my > client. Most of reputed frameworks like Django and Turbo gears are yet in > the 2.x stage. I know that these frameworks are extremely good. But I wanted > to build my base with python 3 as that is what is going to prevail in the > future. > > I have built my own little architecture using python3. Here is what I have > accomplished till now: > > a) A multiprocessing webserver built directly using low level sockets for > maximum control, conforming to RFC 2616 (not completely right now). > b) A HTTP message parser for parsing HTTP/1.1 requests and generating > response messages > c) A session control base using python multiprocessing dictionary manager > d) A partially build MVC model, without a templating engine at the moment. > I am planning to put Jinja 3 there. > > I have spent months of free time doing this. I have learnt a lot, but well > I am not sure if the path I am on is the right one. > > My question to everyone is whether I should go ahead with this approach, or > should I just use 2.x technology? I am not sure if I will be able to port > all the code to python3 later. > > I will really appreciate any input. > > Thanks and regards, > Navkirat > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- Jorge Romero -- http://mail.python.org/mailman/listinfo/python-list
Re: MySQLdb SEC_TO_TIME function returns datetime.timedelta class
On Sun, May 15, 2011 at 11:50 PM, Chris Angelico wrote: > On Mon, May 16, 2011 at 10:42 AM, Jorge Romero > wrote: > > Hi Pythonists, > > I'm retrieving some time data from a MySQL database using Python's > MySQLdb > > library. Here's the situation, I got a time field on MySQL given in > seconds, > > I need it on HH:MM:SS format, so I'm SELECTING that field with > SEC_TO_TIME > > function, something like this: > > query = "SELECT SEC_TO_TIME(SUM(seconds)) FROM table" > > You're summing a column, so presumably the values are actually deltas > (it doesn't make sense, for instance, to add Tues March 16th to Sat > Nov 2nd). The result exceeds a day; in what format do you actually > want it? > > For maximum flexibility, you could ditch the SEC_TO_TIME call and > simply work with the integer seconds in Python. You can then format > that into H:MM:SS or whatever suits you. > > Chris Angelico > -- > http://mail.python.org/mailman/listinfo/python-list > Yeah, I believe that's the way to go, retrieve seconds and deal with them with Python, for flexibility as you pointed. I need the seconds to become HH:MM:SS format. What seems weird to me is why MySQLdb treats the result of the query as deltas. Here's what I get if a query directly the database, output from PHP MyAdmin: SEC_TO_TIME(SUM(billsec)) *79:30:09* * * *This value suits better the datetime.time type, instead of datetime.deltatime. * Thanks Chris for your feedback. -- Jorge Romero -- http://mail.python.org/mailman/listinfo/python-list
MySQLdb SEC_TO_TIME function returns datetime.timedelta class
Hi Pythonists, I'm retrieving some time data from a MySQL database using Python's MySQLdb library. Here's the situation, I got a time field on MySQL given in seconds, I need it on HH:MM:SS format, so I'm SELECTING that field with SEC_TO_TIME function, something like this: query = "SELECT SEC_TO_TIME(SUM(seconds)) FROM table" fetched = cursor.execute(query) return fetched[0] The result of the query is given to me as *datetime.timedelta *type, which has an undesired print behavior for my purposes: >>> query = "SELECT SEC_TO_TIME(SUM(seconds)) FROM table" >>> fetched = cursor.execute(query) >>> print fetched[0] 3 days, 7:30:09 >>> print type(fetched[0]) Instead of *datetime.timedelta *I need *datetime.time *type. Does anybody knows how to change this behavior or is it something I must deal with my code? Thanks in advanced. -- Jorge Romero -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7 Debian 6.0. Squeeze
Actually came back with some feedback to my own question. The following repositories do the job: # /etc/apt/sources.list deb http://ftp.uk.debian.org/debian/ unstable main contrib non-free deb http://ftp.uk.debian.org/debian/ experimental main contrib non-free deb http://security.debian.org/ testing/updates main contrib $ apt-get update $ apt-get install python2.7 $ python --version Python 2.6.6 $ python2.7 --version Python 2.7.1+ If you need 2.7 as default runtime: $ update-alternatives --install /usr/bin/python python /usr/bin/python2.7 10 This is the first time I need two Python instances, so might helpful for someone in the same position. Any further help feel free to reply. Cheers. On Thu, May 12, 2011 at 11:27 AM, Jorge Romero wrote: > Hi all, > > My machine is running Debian Squeeze so my default Python runtime is 2.6.6. > > According to Python docs *optparse* library is deprecated and the > development will be moved to *argparse*, which is new in Python 2.7.1. So > now that I'm about to write a script that parse command line arguments > thought would be a good idea to do the transition right now, besides the > good comments about this version. > > I tried Googling about Python 2.7 on Debian Squeeze, but did not find > anything but discussions -.-. Anyone out there that can point me some > helpful material or anyone who had luck running 2.7 on Debian? > > Thanks in advanced. > > -- > Jorge Romero > > -- Jorge Romero -- http://mail.python.org/mailman/listinfo/python-list
Python 2.7 Debian 6.0. Squeeze
Hi all, My machine is running Debian Squeeze so my default Python runtime is 2.6.6. According to Python docs *optparse* library is deprecated and the development will be moved to *argparse*, which is new in Python 2.7.1. So now that I'm about to write a script that parse command line arguments thought would be a good idea to do the transition right now, besides the good comments about this version. I tried Googling about Python 2.7 on Debian Squeeze, but did not find anything but discussions -.-. Anyone out there that can point me some helpful material or anyone who had luck running 2.7 on Debian? Thanks in advanced. -- Jorge Romero -- http://mail.python.org/mailman/listinfo/python-list
