Re: Getting Syslog working on OSX Monterey

2022-03-03 Thread Philip Bloom via Python-list
Grabbing latest python that does work.  Good we're about to get out of the
stone ages a bit here.

So findings:
Syslog - works in 3.10, broken against monterey in 3.6.
Logging.Handlers.Sysloghandler - is broken in both against Monterey.

Will bug it for the tracker.  Thanks for the feedback.




On Thu, Mar 3, 2022 at 10:32 AM Barry Scott  wrote:

>
>
> On 3 Mar 2022, at 03:01, Philip Bloom  wrote:
>
> I'm probably asking on the wrong list, and probably should bother wherever
> apple's ASL experts live for changes in monterey.   Guess nobody else is
> seeing this?
>
> The same exact code is working just fine on OSX Big Sur, but on OSX
> Monterey it doesn't work at all.  Users that haven't updated are having the
> program produce logs as it has for years through
> logging.handlers.SysLogHandler.  Mac OSX definitely has a listening socket
> at '/var/run/syslog' which shows up in Console.app.
>
> Apologies, Barry.  I'm not quite understanding your responses.
>
>
> This works:
>
> syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_USER)
> syslog.syslog(syslog.LOG_NOTICE, 'QQQ test log')
>
> I see the "QQQ test log" when I run syslog command.
>
> And I can reproduce that logging.handlers.SysLogHandler does not work.
> I added debug to the SysLogHandler() code and see that it does indeed
> write into the /var/run/syslog socket.
> I suspect that macOS /var/run/syslog does not implement the RFC that this
> code depends on, but that a wild guess.
>
> I suggest that you write your own handler that uses syslog.syslog() and
> use that.
>
> Barry
>
>
> When we say OSX has no listener for Syslog, what is the Apple System Log
> and the general output to Console.app then?  I thought that was the local
> syslog on OSX and had, for years, been behaving as such when using
> logging.handlers.SysLogHandler with a config in /etc/asl/ to define how it
> should be routed and the rollover/cleanup frequency.
>
> Thanks for replying, just having trouble understanding.
>
>
> On Mon, Feb 28, 2022 at 2:07 PM Barry Scott 
> wrote:
>
>>
>>
>> > On 28 Feb 2022, at 21:41, Peter J. Holzer  wrote:
>> >
>> > On 2022-02-27 22:16:54 +, Barry wrote:
>> >> If you look at the code of the logging modules syslog handle you will
>> see that
>> >> it does not use syslog. It’s assuming that it can network to a syslog
>> listener.
>> >> Such a listener is not running on my systems as far as I know.
>> >>
>> >> I have always assumed that if I want a logger syslog handler that I
>> would have
>> >> to implement it myself. So far I have code that uses syslog directly
>> and have
>> >> not written that code yet.
>> >
>> > What do you mean by using syslog directly? The syslog(3) library
>> > function also just sends messages to a "syslog listener" (more commonly
>> > called a syslog daemon) - at least on any unix-like system I'm familiar
>> > with (which doesn't include MacOS). It will, however, always use the
>> > *local* syslog daemon - AFAIK there is no standard way to open a remote
>> > connection (many syslog daemons can be configured to forward messages to
>> > a remote server, however).
>>
>> I'm re-reading the code to check on what I'm seeing. (Its been a long
>> time since I last look deeply at this code).
>>
>> You can write to /dev/log if you pass that to
>> SysLogHandler(address='/dev/log'), but the default is to use a socket
>> to talk to a network listener on localhost:514. There are no deamons
>> listening on port 514 on my Fedora systems or mac OS.
>>
>> That is not what you would expect as the default if you are using the C
>> API.
>>
>> What you do not see used in the SyslogHandler() is the import syslog
>> and hence its nor using openlog() etc from syslog API.
>>
>> Barry
>>
>>
>>
>> >hp
>> >
>> > --
>> >   _  | Peter J. Holzer| Story must make more sense than reality.
>> > |_|_) ||
>> > | |   | h...@hjp.at |    -- Charles Stross, "Creative writing
>> > __/   | http://www.hjp.at/ |   challenge!"
>> > --
>> > https://mail.python.org/mailman/listinfo/python-list
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
> --
> Philip Bloom
> Director, Services Engineering
> *AppLovin Corporation*
> M: (786)-338-1439 <786-338-1439>
> [image: LinkedIn] <https://www.linkedin.com/company/applovin> [image:
> Twitter] <https://twitter.com/AppLovin> [image: Facebook]
> <https://facebook.com/AppLovin> [image: Instagram]
> <https://www.instagram.com/applovin/>
> [image: AppLovin] <https://www.applovin.com/>
>
>
>
>
>
>

-- 
Philip Bloom
Director, Services Engineering
*AppLovin Corporation*
M: (786)-338-1439 <786-338-1439>
[image: LinkedIn] <https://www.linkedin.com/company/applovin> [image:
Twitter] <https://twitter.com/AppLovin> [image: Facebook]
<https://facebook.com/AppLovin> [image: Instagram]
<https://www.instagram.com/applovin/>
[image: AppLovin] <https://www.applovin.com/>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Getting Syslog working on OSX Monterey

2022-03-02 Thread Philip Bloom via Python-list
I'm probably asking on the wrong list, and probably should bother wherever
apple's ASL experts live for changes in monterey.   Guess nobody else is
seeing this?

The same exact code is working just fine on OSX Big Sur, but on OSX
Monterey it doesn't work at all.  Users that haven't updated are having the
program produce logs as it has for years through
logging.handlers.SysLogHandler.  Mac OSX definitely has a listening socket
at '/var/run/syslog' which shows up in Console.app.

Apologies, Barry.  I'm not quite understanding your responses.

When we say OSX has no listener for Syslog, what is the Apple System Log
and the general output to Console.app then?  I thought that was the local
syslog on OSX and had, for years, been behaving as such when using
logging.handlers.SysLogHandler with a config in /etc/asl/ to define how it
should be routed and the rollover/cleanup frequency.

Thanks for replying, just having trouble understanding.


On Mon, Feb 28, 2022 at 2:07 PM Barry Scott  wrote:

>
>
> > On 28 Feb 2022, at 21:41, Peter J. Holzer  wrote:
> >
> > On 2022-02-27 22:16:54 +, Barry wrote:
> >> If you look at the code of the logging modules syslog handle you will
> see that
> >> it does not use syslog. It’s assuming that it can network to a syslog
> listener.
> >> Such a listener is not running on my systems as far as I know.
> >>
> >> I have always assumed that if I want a logger syslog handler that I
> would have
> >> to implement it myself. So far I have code that uses syslog directly
> and have
> >> not written that code yet.
> >
> > What do you mean by using syslog directly? The syslog(3) library
> > function also just sends messages to a "syslog listener" (more commonly
> > called a syslog daemon) - at least on any unix-like system I'm familiar
> > with (which doesn't include MacOS). It will, however, always use the
> > *local* syslog daemon - AFAIK there is no standard way to open a remote
> > connection (many syslog daemons can be configured to forward messages to
> > a remote server, however).
>
> I'm re-reading the code to check on what I'm seeing. (Its been a long
> time since I last look deeply at this code).
>
> You can write to /dev/log if you pass that to
> SysLogHandler(address='/dev/log'), but the default is to use a socket
> to talk to a network listener on localhost:514. There are no deamons
> listening on port 514 on my Fedora systems or mac OS.
>
> That is not what you would expect as the default if you are using the C
> API.
>
> What you do not see used in the SyslogHandler() is the import syslog
> and hence its nor using openlog() etc from syslog API.
>
> Barry
>
>
>
> >hp
> >
> > --
> >   _  | Peter J. Holzer| Story must make more sense than reality.
> > |_|_) ||
> > | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> > __/   | http://www.hjp.at/ |   challenge!"
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Philip Bloom
Director, Services Engineering
*AppLovin Corporation*
M: (786)-338-1439 <786-338-1439>
[image: LinkedIn] <https://www.linkedin.com/company/applovin> [image:
Twitter] <https://twitter.com/AppLovin> [image: Facebook]
<https://facebook.com/AppLovin> [image: Instagram]
<https://www.instagram.com/applovin/>
[image: AppLovin] <https://www.applovin.com/>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Getting Syslog working on OSX Monterey

2022-02-27 Thread Philip Bloom via Python-list
Thanks.  Had tried it with no address, which defaults to ('localhost',
'514') as well as address='/var/run/syslog' which had been working
previously, and the doc recommends as:
For example, on Linux it’s usually ‘/dev/log’ but on OS/X it’s
‘/var/run/syslog’. You’ll need to check your platform and use the
appropriate address (you may need to do this check at runtime if your
application needs to run on several platforms)

Aiming for this to be being picked up on the same computer I'm running the
test script (Python -> Logging -> SyslogHandler -> Mac OS Syslogd -> parsed
ASL config -> /var/log/Appname/Appname.log).   It's why I think I may be
missing something fundamental, but it feels like something subtle changed
in the latest OSX.

On Sun, Feb 27, 2022 at 11:26 AM Dennis Lee Bieber 
wrote:

> On Sun, 27 Feb 2022 08:34:21 -0800, Philip Bloom
>  declaimed the following:
>
> >
> >sys_handler = SysLogHandler(address='/var/run/syslog')
>
> As I read the documentation, the address is supposed to be the
> NETWORK
> address of the machine to receive the log messages...
>
> https://docs.python.org/3/library/logging.handlers.html#sysloghandler
>
> >#sys_handler.encodePriority(SysLogHandler.LOG_USER,
> SysLogHandler.LOG_ALERT)
> ># Tried with the above, but didn't make a difference.  Neither did not
> >defining the address and letting it go to local host.
> >sys_handler.setFormatter(syslog_format)
> >root_logger.addHandler(sys_handler)
> >
> >logging.critical("This is a test")
> >logging.error("This is a test error")
> >logging.info("Still a test")
> >logging.debug("Testy test")
> >
> >Using command line: Oddly, this gets to Console.Apps messages from device
> >reliably, though doesn't get picked up by syslog -w or get received by the
> >ASL config redirect:
> >syslog -s -l error -k Message "appName: this is a test2"
> >syslog -s -l notice -k Message "appName: this is a test3"
> >
> >ASL configuration, which is loaded according to syslog -config:
> >> /var/log/appName/appName.log mode=0640 compress format=std rotate=seq
> >file_max=50M all_max=500M
> >? [CA= Sender appName] file /var/log/appName/appName.log
> >
> >My end goal is really to get just a working python logging ->
> >var/log/appname/appname.log again so glad to just be pointed in the right
> >direction if way off base.
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.com
> http://wlfraed.microdiversity.freeddns.org/
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Philip Bloom
Director, Services Engineering
*AppLovin Corporation*
M: (786)-338-1439 <786-338-1439>
[image: LinkedIn] <https://www.linkedin.com/company/applovin> [image:
Twitter] <https://twitter.com/AppLovin> [image: Facebook]
<https://facebook.com/AppLovin> [image: Instagram]
<https://www.instagram.com/applovin/>
[image: AppLovin] <https://www.applovin.com/>
-- 
https://mail.python.org/mailman/listinfo/python-list


Getting Syslog working on OSX Monterey

2022-02-27 Thread Philip Bloom via Python-list
Hello,

First time mailing and looking for help/guidance.  Hopefully not too in the
wrong place.

We've had an app with logging to a /var/log for many years through
logging.sysloghandler.  Recently, though, I noticed that it suddenly was
getting no logs whatsoever over there and investigated, believing the
recent triggering change was upgrading to Mac OSX 12 (Monterey).

My understanding is a bit primitive, but our config had never been hard to
follow previously and I may be missing something fundamental.  I've looked
over a number of online examples but they don't seem to be running
correctly either.  I'm on Python 3.6.8 (though we're about to start an
upgrade to the latest stable, if that in theory may have changes to syslog
handling).  I'm mostly ending up here since I'm finding such differences in
response between python modules I'd expect to be fairly similar.

Separating into a test script I've been testing with logging.SysLogHandler,
syslog, and the command line 'syslog -s'.  Replaced all below with a
placeholder appName but it's normally a fairly unique setupCDNGUI name.

Example with syslog (python module):  - This will show up in System.log but
not in Apple's Console for all messages to device, though won't get all the
way to file.
import syslog
syslog.syslog(syslog.LOG_NOTICE, 'AppName: THIS IS A TEST - Processing
started')
syslog.syslog(syslog.LOG_ERR, 'AppName: THIS IS A TEST ERROR - Processing
started')

Example with SyslogHandler: - This doesn't seem to show up anywhere besides
the screen log, which is odd to me as reading the docs, I understood this
to be a logging integration into the syslog module, so expected similar
behavior in at least what was sent out.  Syslog handler is definitely
picked up in logging.handlers

root_logger = logging.getLogger()
root_logger.setLevel(logging.DEBUG)
basic_datefmt = '%m/%d/%Y %I:%M:%S %p'

formatter = logging.Formatter(fmt='%(asctime)s %(levelname)s: %(message)s',
datefmt=basic_datefmt)
syslog_format = logging.Formatter(fmt='SetupCDNGUI: %(message)s',
datefmt=basic_datefmt)

scrhandler = logging.StreamHandler()
scrhandler.setFormatter(formatter)
root_logger.addHandler(scrhandler)

sys_handler = SysLogHandler(address='/var/run/syslog')
#sys_handler.encodePriority(SysLogHandler.LOG_USER, SysLogHandler.LOG_ALERT)
# Tried with the above, but didn't make a difference.  Neither did not
defining the address and letting it go to local host.
sys_handler.setFormatter(syslog_format)
root_logger.addHandler(sys_handler)

logging.critical("This is a test")
logging.error("This is a test error")
logging.info("Still a test")
logging.debug("Testy test")

Using command line: Oddly, this gets to Console.Apps messages from device
reliably, though doesn't get picked up by syslog -w or get received by the
ASL config redirect:
syslog -s -l error -k Message "appName: this is a test2"
syslog -s -l notice -k Message "appName: this is a test3"

ASL configuration, which is loaded according to syslog -config:
> /var/log/appName/appName.log mode=0640 compress format=std rotate=seq
file_max=50M all_max=500M
? [CA= Sender appName] file /var/log/appName/appName.log

My end goal is really to get just a working python logging ->
var/log/appname/appname.log again so glad to just be pointed in the right
direction if way off base.

-- 
Philip Bloom
Director, Services Engineering
*AppLovin Corporation*
M: (786)-338-1439 <786-338-1439>
[image: LinkedIn] <https://www.linkedin.com/company/applovin> [image:
Twitter] <https://twitter.com/AppLovin> [image: Facebook]
<https://facebook.com/AppLovin> [image: Instagram]
<https://www.instagram.com/applovin/>
[image: AppLovin] <https://www.applovin.com/>
-- 
https://mail.python.org/mailman/listinfo/python-list


Strange os.stat behavior

2010-09-29 Thread Philip Bloom
I'm on python 2.6.1:

 

Ran into some os.stat behavior that knocked me for a loop.  I was using
os.stat to retrieve file st_ctime and st_mtime from a remote server
through a unc path, and doing this I encountered that os.stat was
returning me st_ctime and st_mtime values  that were months off,
reporting values that not only were months in the past, but also
relatively wrong (Reporting a greater difference between Modified and
Created than there should be).  Below, run through localtime and
formatted a little for easier reading.).  C++ stat, Win32API, and
Windows own directory report all match with the same seen time (and are
correct).  Has anyone seen something like this before?   It's quite
scary to me that os.stat is returning a different value that it's
getting from somewhere and doesn't match with either the Windows API or
the C++ stat library.  I read over the release notes for 2.6.x and
didn't see any mention of os.stat relevant bugs or fixes.  I'm curious
what it could possibly be doing differently than the others (I thought
it used the windows api under the hood for Windows nt derived systems).

 

Ex:

\\mpkarc01\Build_stats\tras\MayaExportKernel_p.config\mabahazy~RWCWRK_70
01470.stats\9-27-2010_log.txt 1279755701.87 1285810489.65

Created:  time.struct_time(tm_year=2010, tm_mon=7, tm_mday=21,
tm_hour=16, tm_min=41, tm_sec=41, tm_wday=2, tm_yday=202, tm_isdst=1)

Modified:  time.struct_time(tm_year=2010, tm_mon=7, tm_mday=25,
tm_hour=0, tm_min=59, tm_sec=45, tm_wday=6, tm_yday=206, tm_isdst=1),
raw: 1280044785

Accessed:  time.struct_time(tm_year=2010, tm_mon=9, tm_mday=29,
tm_hour=17, tm_min=25, tm_sec=31, tm_wday=2, tm_yday=272, tm_isdst=1)

Raw Time.Time(): time.struct_time(tm_year=2010, tm_mon=9, tm_mday=29,
tm_hour=18, tm_min=34, tm_sec=49, tm_wday=2, tm_yday=272, tm_isdst=1),
raw: 1285810489.65

Win32API Ctime: 09/27/10 20:18:11 

Win32API MTime: 09/28/10 01:18:37

Win32API ATime: 09/29/10 00:24:46 

 

Relevant code segment:

import win32api

import win32con

import win32file

import time

import os

...

 
statinfo = os.stat(os.path.join(root, name))

print os.path.join(root, name) + " " +
str(statinfo.st_ctime) + " " + str(time.time())

print "Modified: ",
time.localtime(int(statinfo.st_mtime)),int(statinfo.st_mtime)

print "Created: ",
time.localtime(int(statinfo.st_ctime))

print "Accessed: ",
time.localtime(int(statinfo.st_atime))

print time.localtime(),time.time()

fh = win32file.CreateFile(os.path.join(root,
name), win32file.GENERIC_READ | win32file.GENERIC_WRITE, 0, None,
win32file.OPEN_EXISTING,0, 0)

sts, creationTime, accessTime, writeTime =
win32file.GetFileTime(fh)

print creationTime, accessTime, writeTime

win32file.CloseHandle(fh)

 

 

Platform of executing code: Windows XP, 64 bit.


__
This email has been scanned by the MessageLabs
__-- 
http://mail.python.org/mailman/listinfo/python-list


RE: Speed-up for loops

2010-09-02 Thread Philip Bloom
Uh.  

Try:
Imax=10
a=0
i=0
While(imailto:python-list-bounces+pbloom=crystald@python.org] On Behalf Of
Nobody
Sent: Thursday, September 02, 2010 9:05 AM
To: python-list@python.org
Subject: Re: Speed-up for loops

On Thu, 02 Sep 2010 12:02:40 +0200, Michael Kreim wrote:

> I was comparing the speed of a simple loop program between Matlab and 
> Python.

> imax = 10
> a = 0
> for i in xrange(imax):
>  a = a + 10
> print a

> Are there any ways to speed up the for/xrange loop?

Sure; the above can be reduced to just:

print imax * 10
;)

More seriously, if you're comparing against Matlab, you should look at
NumPy. If there's a reasonably direct approach using NumPy, it will be
much quicker than a Python "for" loop (in a sense, NumPy is a library of
useful "for" loops implemented in C).

Even a fairly indirect NumPy approach is often quicker than pure Python.

-- 
http://mail.python.org/mailman/listinfo/python-list

__
This email has been scanned by the MessageLabs
__

__
This email has been scanned by the MessageLabs
__
-- 
http://mail.python.org/mailman/listinfo/python-list


RE: Question on periods in strings

2009-03-12 Thread Philip Bloom
Thanks.  I now know the cause of this, the suggestion to fling it in a few 
languages made it obvious.  All of them were sharing the issue.  Specifically 
that Trend MicroOffice Scan was the stalling factor, which was significantly 
boosting write times and if the write had any periods it would send it way off 
into the moon.  So yeah, the antivirus program was the culprit.

  Python was interestingly less affected than C# which saw a 15 times slowdown 
from the same effect.

Anyhow, sorry for bothering the list on what is clearly not a python problem, 
but thanks as well for helping lead me to the bottom of this mystery.


 -Original Message-
From: python-list-bounces+pbloom=crystald@python.org 
[mailto:python-list-bounces+pbloom=crystald@python.org] On Behalf Of 
Gabriel Genellina
Sent: Thursday, March 12, 2009 12:42 AM
To: python-list@python.org
Subject: Re: Question on periods in strings

En Wed, 11 Mar 2009 23:42:45 -0200, Philip Bloom   
escribió:

> Thanks for the welcome :)
>
> You're right.  Here's with the missed line (I was cutting out commented  
> parts).  Hopefully these are all cut/paste-able.
>
> #test A
> #runs in 5.8 seconds.
> from datetime import datetime
> testvar2='9a00'
> startTime = datetime.now()
> filehandle=open('testwriting.txt','w')
> for var in range(1000):
> filehandle.write(testvar2)
> filehandle.close()
> print (datetime.now() - startTime)
>
>
> #test B
> [using '9.00' -- otherwise identical]
>
> I do use the same filename, but I've run the tests in different orders  
> and it's made no difference.  Repeatedly running the same test results  
> in the same numbers with only minor fluctuations (as would be expected  
> from cache issues).  Ten runs in a row of Test B all result in about 11  
> seconds each.  Ten runs in a row of Test A all result in about 6 seconds  
> each.

I could not reproduce this. You've got better hardware than mine,  
certainly (I had to remove a 0 to get reasonable times) but I got almost  
identical results with both versions. I've tested also with 3.0 (and I had  
to take another 0 off!) with the same results.
I have no idea why you see a difference. Unless the antivirus is  
interfering, or you have some crazy driver monitoring disk activity and  
the dot triggers something...
Try using a different language - I'd say this is totally unrelated to  
Python.

-- 
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__
--
http://mail.python.org/mailman/listinfo/python-list


RE: Question on periods in strings

2009-03-11 Thread Philip Bloom
Thanks for the welcome :)

You're right.  Here's with the missed line (I was cutting out commented parts). 
 Hopefully these are all cut/paste-able.

#test A
#runs in 5.8 seconds.
from datetime import datetime
testvar2='9a00'
startTime = datetime.now()
filehandle=open('testwriting.txt','w')
for var in range(1000):
filehandle.write(testvar2)
filehandle.close()
print (datetime.now() - startTime)


#test B
#runs in 10.9 seconds.
from datetime import datetime
testvar2='9.00'
startTime = datetime.now()
filehandle=open('testwriting.txt','w')
for var in range(1000):
filehandle.write(testvar2)
filehandle.close()
print (datetime.now() - startTime)

I do use the same filename, but I've run the tests in different orders and it's 
made no difference.  Repeatedly running the same test results in the same 
numbers with only minor fluctuations (as would be expected from cache issues).  
Ten runs in a row of Test B all result in about 11 seconds each.  Ten runs in a 
row of Test A all result in about 6 seconds each.

The range is not actually a meaningful adjustment as the time results are 
identical switching out xrange (as I believe they should be since in 2.6 range 
maps to xrange for the most part according to some of the docs).  

#Test C
#runs in 8.9 seconds.
from datetime import datetime
testvar2='9.00'
startTime = datetime.now()
join=[]
filehandle=open('testwriting.txt','w')
for var in range(1000):
join.append(testvar2)
"".join(join)
print (datetime.now() - startTime) #3.01 seconds   
filehandle.write("".join(join))
filehandle.close()
print (datetime.now() - startTime) #8.9 seconds.

#Test D
#runs in 3.8 seconds.
from datetime import datetime
testvar2='9a00'
startTime = datetime.now()
join=[]
filehandle=open('testwriting.txt','w')
for var in range(1000):
join.append(testvar2)
"".join(join)
print (datetime.now() - startTime) #3.09 seconds   
filehandle.write("".join(join))
filehandle.close()
print (datetime.now() - startTime) #3.87 seconds.

This is a variation that shows it more noticeably.  I do an extra join to 
demonstrate that's not taking the time.  Effectively nothing is really 
different it seems like other than the period.  It's all intentionally small 
python code since it originated from just seeing what some variations on file 
writes might differ in scaling.
 
-Original Message-
From: python-list-bounces+pbloom=crystald@python.org 
[mailto:python-list-bounces+pbloom=crystald@python.org] On Behalf Of 
Gabriel Genellina
Sent: Wednesday, March 11, 2009 6:17 PM
To: python-list@python.org
Subject: Re: Question on periods in strings

En Wed, 11 Mar 2009 22:35:22 -0200, Philip Bloom   
escribió:

> Hello, this is my first time posting to the list, but my curiosity here
> is great.

Welcome!

> I was randomly toying with file writes and I ran into something that
> seemed quite odd to me.  When a period is in a string, file write takes
> about double the time.  I saw similar things with newlines, but I
> figured that was because it was doing a lookup on the escape-d n.  All
> other symbols seem to not have this problem, so I'm curious what's
> special about periods that they take so much longer to write to file.

I doubt the period is actually the culprit. There are lots of other  
variables - like disk and memory fragmentation, cpu load, ...
You omitted part of your code: do you use the same filename on both tests?  
(Note that starting with an empty file is not the same as using a  
preallocated file).
Also, do you always run both scripts in the same order? (maybe "the  
second" always runs faster, no matter which one is it).
Also note that you're measuring the time to allocate a list containing ten  
million integer objects (the range() call). xrange is a less perturbing  
option.

-- 
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__
--
http://mail.python.org/mailman/listinfo/python-list


Question on periods in strings

2009-03-11 Thread Philip Bloom
Hello, this is my first time posting to the list, but my curiosity here
is great.

I was randomly toying with file writes and I ran into something that
seemed quite odd to me.  When a period is in a string, file write takes
about double the time.  I saw similar things with newlines, but I
figured that was because it was doing a lookup on the escape-d n.  All
other symbols seem to not have this problem, so I'm curious what's
special about periods that they take so much longer to write to file.

#Done in python 2.6.1
#runs in 5.8 seconds.

from datetime import datetime

testvar2='9a00'

startTime = datetime.now()

for var in range(1000):

filehandle.write(testvar2)

filehandle.close()

print (datetime.now() - startTime)

 

 

#runs in 10.9 seconds.

from datetime import datetime

testvar2='9.00'

startTime = datetime.now()

for var in range(1000):

filehandle.write(testvar2)

filehandle.close()

print (datetime.now() - startTime)

Thank you to any who answer for assuaging my curiosity.


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__--
http://mail.python.org/mailman/listinfo/python-list