Python-list Digest, Vol 77, Issue 7 *
Rohit Roger$
rohitraj007 at gmail.com
Mon Feb 1 05:26:13 EST 2010
Hello
Help for datetime module
Source code is :
*from *datetime *import *datetime
d = datetime(datetime.now().year, datetime.now().month, datetime.now().day,
11, 59, 0 )
print d
On Mon, Feb 1, 2010 at 3:44 PM, <python-list-request at python.org> wrote:
> Junk Score: 2 out of 10 (below your Auto Allow threshold<https://www.boxbe.com/mail-screening>)
> | Approve sender <https://www.boxbe.com/anno?tc=1488077305_3972850> | Block
> sender <https://www.boxbe.com/anno?tc=1488077305_3972850&disp=b> | Block
> domain <https://www.boxbe.com/anno?tc=1488077305_3972850&disp=b&dom>
>
> Send Python-list mailing list submissions to
> python-list at 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-request at python.org
>
> You can reach the person managing the list at
> python-list-owner at 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: whassup? builtins? python3000? Naah can't be right?
> (Andrej Mitrovic)
> 2. gmtime (gazza)
> 3. Re: A performance issue when using default value (keakon)
> 4. Re: HTML Parser which allows low-keyed local changes?
> (Stefan Behnel)
> 5. how long a Str can be used in this python code segment?
> (Stephen.Wu)
> 6. Re: gmtime (Gary Herron)
> 7. Re: how long a Str can be used in this python code segment?
> (Chris Rebert)
> 8. Re: how long a Str can be used in this python code segment?
> (Gary Herron)
> 9. Re: Keyboard input (Dennis Lee Bieber)
> 10. Re: how long a Str can be used in this python code segment?
> (Stephen.Wu)
> 11. Re: how long a Str can be used in this python code segment?
> (Stefan Behnel)
> 12. Re: PEP 3147 - new .pyc format (Daniel Fetchinson)
>
>
> ---------- Forwarded message ----------
> From: Andrej Mitrovic <andrej.mitrovich at gmail.com>
> To:
> Date: Sun, 31 Jan 2010 20:01:57 -0800 (PST)
> Subject: Re: whassup? builtins? python3000? Naah can't be right?
> Hey, it's really simple! Just like the excerpt from the Learning
> Python book says:
>
> "Really, the built-in scope is just a built-in module called builtins,
> but
> you have to import builtins to query built-ins because the name
> builtins is not itself
> built-in...."
>
> :)
>
>
>
> ---------- Forwarded message ----------
> From: gazza <burslem2001 at yahoo.com>
> To:
> Date: Sun, 31 Jan 2010 13:27:46 -0800 (PST)
> Subject: gmtime
> Hi,
>
> I am trying to discover how to obtain the correct time of say CST/
> America and EST/America in python?
>
> Any help on this would be appreciated.
>
>
> Thanks,
> Garyc
>
>
>
> ---------- Forwarded message ----------
> From: keakon <keakon at gmail.com>
> To:
> Date: Sun, 31 Jan 2010 21:20:28 -0800 (PST)
> Subject: Re: A performance issue when using default value
> Even this style is 41 times faster than h2():
>
> def i2(x=[]):
> y = x
> if not y: # add this line
> y = [] # add this line
> y.append(1)
> return y + []
>
> print Timer('i2()','from __main__ import f2, g2, h2, i2').timeit
> (TIMES)
>
> Time: 0.00742356919664
>
>
>
> ---------- Forwarded message ----------
> From: Stefan Behnel <stefan_ml at behnel.de>
> To:
> Date: Mon, 01 Feb 2010 09:34:28 +0100
> Subject: Re: HTML Parser which allows low-keyed local changes?
> Robert, 31.01.2010 20:57:
> > I tried lxml, but after walking and making changes in the element tree,
> > I'm forced to do a full serialization of the whole document
> > (etree.tostring(tree)) - which destroys the "human edited" format of the
> > original HTML code. makes it rather unreadable.
>
> What do you mean? Could you give an example? lxml certainly does not
> destroy anything it parsed, unless you tell it to do so.
>
> Stefan
>
>
>
> ---------- Forwarded message ----------
> From: "Stephen.Wu" <54wutong at gmail.com>
> To: python-list at python.org
> Date: Mon, 1 Feb 2010 01:17:09 -0800 (PST)
> Subject: how long a Str can be used in this python code segment?
> tmp=file.read() (very huge file)
> if targetStr in tmp:
> print "find it"
> else:
> print "not find"
> file.close()
>
> I checked if file.read() is huge to some extend, it doesn't work, but
> could any give me some certain information on this prolbem?
>
>
>
>
> ---------- Forwarded message ----------
> From: Gary Herron <gherron at islandtraining.com>
> To: "python-list at python.org" <python-list at python.org>
> Date: Mon, 01 Feb 2010 01:23:31 -0800
> Subject: Re: gmtime
> gazza wrote:
>
>> Hi,
>>
>> I am trying to discover how to obtain the correct time of say CST/
>> America and EST/America in python?
>>
>> Any help on this would be appreciated.
>>
>>
>> Thanks,
>> Garyc
>>
>>
> The datetime module should give you all you need.
>
> Gary Herron
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Chris Rebert <clp2 at rebertia.com>
> To: "Stephen.Wu" <54wutong at gmail.com>
> Date: Mon, 1 Feb 2010 01:26:55 -0800
> Subject: Re: how long a Str can be used in this python code segment?
> On Mon, Feb 1, 2010 at 1:17 AM, Stephen.Wu <54wutong at gmail.com> wrote:
> > tmp=file.read() (very huge file)
> > if targetStr in tmp:
> > print "find it"
> > else:
> > print "not find"
> > file.close()
> >
> > I checked if file.read() is huge to some extend, it doesn't work, but
> > could any give me some certain information on this prolbem?
>
> If the file's contents is larger than available memory, you'll get a
> MemoryError. To avoid this, you can read the file in by chunks (or if
> applicable, by lines) and see if each chunk/line matches.
>
> Cheers,
> Chris
> --
> http://blog.rebertia.com
>
>
>
> ---------- Forwarded message ----------
> From: Gary Herron <gherron at islandtraining.com>
> To:
> Date: Mon, 01 Feb 2010 01:29:20 -0800
> Subject: Re: how long a Str can be used in this python code segment?
> Stephen.Wu wrote:
>
>> tmp=file.read() (very huge file)
>> if targetStr in tmp:
>> print "find it"
>> else:
>> print "not find"
>> file.close()
>>
>> I checked if file.read() is huge to some extend, it doesn't work, but
>> could any give me some certain information on this prolbem?
>>
>>
>>
>
> Python has no specific limit on string size other than memory size and
> perhaps 32 bit address space and so on. However, if your file size is even
> a fraction of that size, you should not attempt to read it all into memory
> at once. Is there not a way to process your file in batches of a reasonable
> size?
>
> Gary Herron
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Dennis Lee Bieber <wlfraed at ix.netcom.com>
> To: python-list at python.org
> Date: Mon, 01 Feb 2010 01:31:25 -0800
> Subject: Re: Keyboard input
> On 31 Jan 2010 22:40:55 GMT, Steven D'Aprano
> <steve at REMOVE-THIS-cybersource.com.au> declaimed the following in
> gmane.comp.python.general:
>
> > On Sun, 31 Jan 2010 14:10:34 -0800, Dennis Lee Bieber wrote:
> >
> > > On Sun, 31 Jan 2010 11:51:46 +0000, "Mr.SpOOn" <mr.spoon21 at gmail.com>
> > > declaimed the following in gmane.comp.python.general:
> > >
> > >> 2010/1/29 Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
> > >> >
> > >> > That's strange. If you're using Linux, make sure you have the
> > >> > readline package installed.
> > >>
> > >> I'm using Linux. Ubuntu. I checked on synaptic and I have
> > >> readline-common. Do you mean something else?
> > >>
> > > But was your Python /built/ using readline?
> >
> >
> > How do you ensure that it is?
>
> Well... I think the practice on the Linux variants is to set various
> options when building Python locally. I'm on WinXP and rely upon the
> packagers to build with everything available <G> (and may need to check
> the documentation of those builds as described by the packagers)
>
> It may mean ensuring not only that the runtime library is present,
> but that the development library (C-language header files, etc.) are
> installed.
> --
> Wulfraed Dennis Lee Bieber KD6MOG
> wlfraed at ix.netcom.com HTTP://wlfraed.home.netcom.com/
>
>
>
>
> ---------- Forwarded message ----------
> From: "Stephen.Wu" <54wutong at gmail.com>
> To: python-list at python.org
> Date: Mon, 1 Feb 2010 01:33:09 -0800 (PST)
> Subject: Re: how long a Str can be used in this python code segment?
> On Feb 1, 5:26 pm, Chris Rebert <c... at rebertia.com> wrote:
> > On Mon, Feb 1, 2010 at 1:17 AM, Stephen.Wu <54wut... at gmail.com> wrote:
> > > tmp=file.read() (very huge file)
> > > if targetStr in tmp:
> > > print "find it"
> > > else:
> > > print "not find"
> > > file.close()
> >
> > > I checked if file.read() is huge to some extend, it doesn't work, but
> > > could any give me some certain information on this prolbem?
> >
> > If the file's contents is larger than available memory, you'll get a
> > MemoryError. To avoid this, you can read the file in by chunks (or if
> > applicable, by lines) and see if each chunk/line matches.
> >
> > Cheers,
> > Chris
> > --http://blog.rebertia.com
>
> actually, I just use file.read(length) way, i just want to know what
> exactly para of length I should set, I'm afraid length doesn't equal
> to the amount of physical memory after trials...
>
>
>
> ---------- Forwarded message ----------
> From: Stefan Behnel <stefan_ml at behnel.de>
> To: python-list at python.org
> Date: Mon, 01 Feb 2010 10:45:28 +0100
> Subject: Re: how long a Str can be used in this python code segment?
> Stephen.Wu, 01.02.2010 10:17:
> > tmp=file.read() (very huge file)
> > if targetStr in tmp:
> > print "find it"
> > else:
> > print "not find"
> > file.close()
> >
> > I checked if file.read() is huge to some extend, it doesn't work, but
> > could any give me some certain information on this prolbem?
>
> Others have already pointed out that reading the entire file into memory is
> not a good idea. Try reading chunks repeatedly instead.
>
> As it appears that you simply try to find out if a file contains a specific
> byte sequence, you might find acora interesting:
>
> http://pypi.python.org/pypi/acora
>
> Also note that there are usually platform optimised tools available to
> search content in files, e.g. grep. It's basically impossible to beat their
> raw speed even with hand-tuned Python code, so running the right tool using
> the subprocess module might be a solution.
>
> Stefan
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Fetchinson <fetchinson at googlemail.com>
> To: Python <python-list at python.org>
> Date: Mon, 1 Feb 2010 11:14:42 +0100
> Subject: Re: PEP 3147 - new .pyc format
> > PEP 3147 has just been posted, proposing that, beginning in release
> > 3.2 (and possibly 2.7) compiled .pyc and .pyo files be placed in a
> > directory with a .pyr extension. The reason is so that compiled
> > versions of a program can coexist, which isn't possible now.
> >
> > Frankly, I think this is a really good idea, although I've got a few
> > comments.
> >
> > 1. Apple's MAC OS X should be mentioned, since 10.5 (and presumably
> > 10.6) ship with both Python release 2.3 and 2.5 installed.
> >
> > 2. I think the proposed logic is too complex. If this is installed in
> > 3.2, then that release should simply store its .pyc file in the .pyr
> > directory, without the need for either a command line switch or an
> > environment variable (both are mentioned in the PEP.)
> >
> > 3. Tool support. There are tools that look for the .pyc files; these
> > need to be upgraded somehow. The ones that ship with Python should, of
> > course, be fixed with the PEP, but there are others.
> >
> > 4. I'm in favor of putting the source in the .pyr directory as well,
> > but that's got a couple more issues. One is tool support, which is
> > likely to be worse for source, and the other is some kind of algorithm
> > for identifying which source goes with which object.
>
> I also think the PEP is a great idea and proposes a solution to a real
> problem. But I also hear the 'directory clutter' argument and I'm
> really concerned too, having all these extra directories around (and
> quite a large number of them indeed!). How about this scheme:
>
> 1. install python source files to a shared (among python
> installations) location /this/is/shared
> 2. when python X.Y imports a source file from /this/is/shared it will
> create pyc files in its private area /usr/lib/pythonX.Y/site-packages/
> Time comparison would be between /this/is/shared/x.py and
> /usr/lib/pythonX.Y/site-packages/x.pyc, for instance.
>
> Obviously pythonX.Y needs to know the path to /this/is/shared so it
> can import modules from there, but this can be controlled by an
> environment variable. There would be only .py files in
> /this/is/shared.
>
> Linux distro packagers would only offer a single python-myapp to
> install and it would only contain python source, and the
> version-specific pyc files would be created the first time the
> application is used by python. In /usr/lib/pythonX.Y/site-packages
> there would be only pyc files with magic number matching python X.Y.
>
> So, basically nothing would change only the location of py and pyc
> files would be different from current behavior, but the same algorithm
> would be run to determine which one to load, when to create a pyc
> file, when to ignore the old one, etc.
>
> What would be wrong with this setup?
>
> Cheers,
> Daniel
>
>
> --
> Psss, psss, put it down! - http://www.cafepress.com/putitdown
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100201/29fb206e/attachment.html>
More information about the Python-list
mailing list