Re: Python "why" questions

[Kai Borgolte]

Russ P. wrote:

>> A simple example: Using zero-based indexing, suppose you want to indent
>> the string "spam" so it starts at column 4. How many spaces to you
>> prepend?

No, you won't want to indent a string so it starts at column 4. You
simply want to indent the string by four spaces. Like in PEP 8:

/Use 4 spaces per indentation level./

> 0123456789
>     spam

And of course your text editor will number the columns beginning with
one, so the string starts at column 5.

123456789
    spam
-- 
Kai Borgolte, Bonn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Standish P]

On Aug 19, 8:25 am, c...@tiac.net (Richard Harter) wrote:
> On Wed, 18 Aug 2010 01:39:09 -0700 (PDT), Nick Keighley
>
>  wrote:
> >On 17 Aug, 18:34, Standish P  wrote:
> >> How are these heaps being implemented ? Is there some illustrative
> >> code or a book showing how to implement these heaps in C for example ?

> >any book of algorithms I'd have thought

> >http://en.wikipedia.org/wiki/Dynamic_memory_allocation
> >http://www.flounder.com/inside_storage_allocation.htm


> >I've no idea how good either of these is


> The wikipedia page is worthless.  The flounder page has
> substantial meat, but the layout and organization is a mess.  A
> quick google search didn't turn up much that was general - most
> articles are about implementations in specific environments.

I second your assessment.

What we have is blind leading the blind. "Keith Thompson" A CORPORATE
MINDER - with multiple accounts - on a Crusade to limit discussions of
useful nature on the usenet, must be giving anti-education, pro-
illiteracy corporatists (who did much of studies and development on
TAX-PAYER MONEY, maybe from now on we should fund Indian/Chinese/
Vietnamese/Russian/Cuban companies that have a tradition of sharing
knowledge from the socialist value system) ,lots of joy because that
means more market for their "user-friendly" , "thought-killing"
products and high priced courses.

You will see how consistently, she gives short replies, that have
ZILCH educational contents, compared to the volume of details they
boast on their websites they claim know.

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

Re: Python "why" questions

[Kai Borgolte]

Sorry about my previous posting with wrong references, this one should
be better.

Steven D'Aprano wrote:

>A simple example: Using zero-based indexing, suppose you want to indent 
>the string "spam" so it starts at column 4. How many spaces to you 
>prepend?

No, you won't want to indent a string so it starts at column 4. You
simply want to indent the string by four spaces. Like in PEP 8:

/Use 4 spaces per indentation level./

>0123456789
>spam

And of course your text editor will number the columns beginning with
one, so the string starts at column 5.

123456789
    spam
-- 
Kai Borgolte, Bonn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Assert statements in python 3.1

[Mark Dickinson]

On Aug 20, 6:13 am, genxtech  wrote:
> This is more of a curiosity question then anything else...  I was just
> wondering why in version 3 of python assertions weren't converted to
> use parenthesis, since print was.
>
> I am just asking because it seems the following line of code would
> seem more readable as a function:
>    assert 2 + 2 == 5, "Only for very large values of 2."

Well, part of the idea of asserts is that when you're running with
optimizations turned on (python -O), asserts should be disabled.  But
if assert were a normal function then in

assert(expensive_check)

the argument expensive_check would be evaluated both with 'python' and
with 'python -O'.

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

Re: Reading the access attributes of directories in Windows

[Tim Golden]

I currently do not have subversion access in my PC. I could try to
install a free copy of it. But it you could ptovide an installer, it
certainly would do things easier. Please let me know if it is
possible.


Vicente, can you just confirm that you received the installer I
sent offlist? I'll try to put winsys on PyPI with installers;
just haven't got round to it yes :)

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

Re: Iterative vs. Recursive coding

[News123]

On 08/20/2010 02:26 AM, Steven D'Aprano wrote:
> On Thu, 19 Aug 2010 22:00:16 +, Martin Gregorie wrote:
> 
>> Recursion can be quite a trick to get your mind round at first
> 
> Really? Do people actually find the *concept* of recursion to be tricky?
Is this a sincere surprise or are you just boasting?
> 
> If I remember correctly, my puzzlement about recursion lasted about 15 
> seconds. I remember thinking "How does the function foo know that there 
> is a function foo when foo doesn't fully exist yet?", but once I accepted 
> the fact that it just does it all just seemed obvious. Getting recursion 
> *right* is sometimes tricky, but the idea itself isn't.

Well there's two things where I remember, that at least quite some
people in our class (at least the ones who didn't do maths or
programming in their spare time) had problems with.

This were recursion and Mathematical induction. (quite the same though)

The fact, that you didn't have the issue doens't mean it's easy for others.



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

A question to experienced Pythoneers

[Rony]

Here's the story :
I've been hired by a company as a consultant to reorganise there
development department.
The actual situation is :
The manager of the development has been fired, main reason (what they
told me) is that they have big big troubles in keeping deadlines ! For
there last product, for which they estimated 3 man years of
development they had 9 months extra effort, and the product was
delivered a year to late.

I basicaly have 'carte blanche' :)

One of my plans is to introduce Python as development tool.
They mostly develop back-office software, and at the moment they do it
all in C with MFC.
Another new requirement they have, is that the new product should run
on Win & Mac.

So, my strategie would be :
- Use Python and wxpython for the GUI
- Develop critical routines in Pyrex or in C and make PYD's from it
which will be imported by the main Python programm.
- Distribute with py2exe on Win & py2app for Mac.

What do you think of this ?
Another point of attention is that the software isn't Open Source, it
is a commercial package. So protection of sources is important.
Now I know that anything can be decompiled, even C. The only question
is, how hard is it and how much effort must someone do to decompile
and retro engineer code to understand it.
I think by putting all program logic in Pyd files that I would be
quite secure ?
On a side note : Is it harder to decompile PYD files then PYC files ?

I allready had a meeting with the developpers and did a presentation
of python with wxwindow, mostly with an open source project where I
contribute to the development. They didn't see any big problems to
learn Python fast and they allready know C.

All opinions, advice here is welcome :)

Tia

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

Re: Iterative vs. Recursive coding

[Navkirat Singh]

On 20-Aug-2010, at 1:17 PM, News123 wrote:

> On 08/20/2010 02:26 AM, Steven D'Aprano wrote:
>> On Thu, 19 Aug 2010 22:00:16 +, Martin Gregorie wrote:
>> 
>>> Recursion can be quite a trick to get your mind round at first
>> 
>> Really? Do people actually find the *concept* of recursion to be tricky?
> Is this a sincere surprise or are you just boasting?
>> 
>> If I remember correctly, my puzzlement about recursion lasted about 15 
>> seconds. I remember thinking "How does the function foo know that there 
>> is a function foo when foo doesn't fully exist yet?", but once I accepted 
>> the fact that it just does it all just seemed obvious. Getting recursion 
>> *right* is sometimes tricky, but the idea itself isn't.
> 
> Well there's two things where I remember, that at least quite some
> people in our class (at least the ones who didn't do maths or
> programming in their spare time) had problems with.
> 
> This were recursion and Mathematical induction. (quite the same though)
> 
> The fact, that you didn't have the issue doens't mean it's easy for others.
> 
> 
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list

Well I guess why you did not have a problem understanding recursion is because 
you took for granted that it is the way it is. 
Most people, like me, try to reason why something is the way it is ! Hence, the 
delay in understanding the concept fully. 

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

Re: Iterative vs. Recursive coding

[geremy condra]

On Fri, Aug 20, 2010 at 12:47 AM, News123  wrote:
> On 08/20/2010 02:26 AM, Steven D'Aprano wrote:
>> On Thu, 19 Aug 2010 22:00:16 +, Martin Gregorie wrote:
>>
>>> Recursion can be quite a trick to get your mind round at first
>>
>> Really? Do people actually find the *concept* of recursion to be tricky?
> Is this a sincere surprise or are you just boasting?

I think his point is that the confusion is on how to do it right, not
the concept of it.

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

Re: Python "why" questions

[Martin Braun]

On Thu, Aug 19, 2010 at 07:13:50PM +, Steven D'Aprano wrote:
> Mathematics is an ancient art that values tradition and convention. It 
> doesn't matter how hard it was to come up with a proof, or how difficult 
> to verify it. Mathematicians value logical correctness and some 
> undefinable sense of elegance over how easy it is to verify, the 
> readability of the notation, resistance to errors, and the ability of 
> mediocre mathematicians to make useful contributions. Mathematical 
> notation and conventions are not, by any stretch of the imagination, 
> designed to reduce errors. Mathematicians consider it a good thing that 
> they are still mostly using the same notation invented by (say) Leibniz.

Another thing worth mentioning (I guess here is a good a place as any
other) is the fact that programming and mathematics are still pretty
different things, despite how much we programmers would like to think
ourselves as some kind of mathematician.  
Fields-medal winners are not likely to be writing database applications
in their spare time, or to save up money for blackboards and pencils.

But mathematics is a wide field, and one area I'm very familiar in is
signal processing, which has taken a lot of mathematics to make our
algorithms work. In fact, of all electrical engineering disciplines,
signal processing is probably the most mathematical.

I find this thread extremely interesting, but what surprised me that
everyone seems to agree that mathematics is 1-based, but we Pythoneers
should stick to zero-based. I disagree. To make sure I'm not going
crazy, I took the top five books lying on my desk, which were the DSP
book by Oppenheim/Schafer, two books by Stephen M. Kay (Spectral
Estimation and Estimation Theory) and the Channel Coding book by Lin &
Costello. This is isn't pure mathematics (as in proving the Goldbach
conjecture), but nevertheless, this is serious mathematics and,
surprise, they most exclusively use zero-based notation.
You probably don't have those books in grabbing distance, so here's some
examples for zero-based stuff:

- The definition of the FFT and one-sided z-transform (practically
  everywhere I've seen)
- Time indices for time-discrete signals usually start at 0 for causal
  signals, same goes for filters (impulse responses)
- Vector representation of polynomials
- The Levinson-Durbin recursion algorithm is way more readable with
  zero-based indices (step 0 is an initialisation step)
- Even most matrices used in the context for coding use zero-based
  indexing (i.e., the left-most column is column zero). I would like to
  add that dealing with linear algebra in GF2 is a bit different from
  handling complex signals as in the previous examples, so this is
  something to consider.

I realize a lot of this has it's root in the application, e.g.
shift-registers (index 0 means it's run through 0 shift registers). But
it's been adopted for the mathematics because it's useful there as well
(e.g. because x^0 = 1 for any non-zero value of x).

Both mathematics and programming have two kinds of iterations: where
index matters, and where it doesn't (why not iterate 'apple',
'banana', 'cherry' etc.). In practically all cases I deal with where the
index matters, zero-based suits me better. The one-based indexing Matlab
uses drives me crazy, and that's specifically designed for engineers.

Martin

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association



pgp8yPohaXQUF.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A question to experienced Pythoneers

[geremy condra]

On Fri, Aug 20, 2010 at 1:16 AM, Rony  wrote:
> Here's the story :
> I've been hired by a company as a consultant to reorganise there
> development department.
> The actual situation is :
> The manager of the development has been fired, main reason (what they
> told me) is that they have big big troubles in keeping deadlines ! For
> there last product, for which they estimated 3 man years of
> development they had 9 months extra effort, and the product was
> delivered a year to late.
>
> I basicaly have 'carte blanche' :)
>
> One of my plans is to introduce Python as development tool.
> They mostly develop back-office software, and at the moment they do it
> all in C with MFC.
> Another new requirement they have, is that the new product should run
> on Win & Mac.
>
> So, my strategie would be :
> - Use Python and wxpython for the GUI
> - Develop critical routines in Pyrex or in C and make PYD's from it
> which will be imported by the main Python programm.
> - Distribute with py2exe on Win & py2app for Mac.
>
> What do you think of this ?
> Another point of attention is that the software isn't Open Source, it
> is a commercial package. So protection of sources is important.
> Now I know that anything can be decompiled, even C. The only question
> is, how hard is it and how much effort must someone do to decompile
> and retro engineer code to understand it.
> I think by putting all program logic in Pyd files that I would be
> quite secure ?
> On a side note : Is it harder to decompile PYD files then PYC files ?
>
> I allready had a meeting with the developpers and did a presentation
> of python with wxwindow, mostly with an open source project where I
> contribute to the development. They didn't see any big problems to
> learn Python fast and they allready know C.
>
> All opinions, advice here is welcome :)

1) Don't take this the wrong way, but get in the habit of using proper
grammar and spelling. Especially as a consultant. It will make the job
of convincing people to take you seriously that much easier.

2) Use the tools at hand. If your developers don't know Python, you
could wind up wasting a lot of talent turning a top-notch C developer
into a bottom-tier Python developer, assuming you don't lose them
altogether.

3) Don't rewrite critical code in a new language unless you have
somebody who really knows what the hell they're doing. All you've done
is turn programming's usual first-order ignorance into a much harder
second-order problem.

4) Don't fool yourself into thinking that your code can't be
decompiled. Odds are your code isn't worth decompiling, but it isn't
hard, and a surprising number of people have the requisite skills. It
certainly isn't 'secure'.

Also- in my experience when people say 'I don't see a problem' to a
consultant, what they really mean is 'I don't think you'll be around
long enough for this to be a problem for me', but you may have the
tools to deal with that.

Happy hunting,
Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A question to experienced Pythoneers

[Rony]

On Aug 20, 11:25 am, geremy condra  wrote:

> 1) Don't take this the wrong way, but get in the habit of using proper
> grammar and spelling. Especially as a consultant. It will make the job
> of convincing people to take you seriously that much easier.

I don't take it the wrong way but have an answer :)
I'm French and doing my best to write understandable English...

Thank you for your answers.

> Also- in my experience when people say 'I don't see a problem' to a
> consultant, what they really mean is 'I don't think you'll be around
> long enough for this to be a problem for me', but you may have the
> tools to deal with that.
>

I'll keep this in mind

Thank you

Rony

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

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[Dave Angel]

m_ahlenius wrote:

Hi,

I am relatively new to doing serious work in python.  I am using it to
access a large number of log files.  Some of the logs get corrupted
and I need to detect that when processing them.  This code seems to
work for quite a few of the logs (all same structure)  It also
correctly identifies some corrupt logs but then it identifies others
as being corrupt when they are not.

example error msg from below code:

Could not open the log file: '/disk/7-29-04-02-01.console.log.tar.gz'
Exception: CRC check\
 failed 0x8967e931 != 0x4e5f1036L

When I manually examine the supposed corrupt log file and use
"tar -xzvof /disk/7-29-04-02-01.console.log.tar.gz "  on it, it opens
just fine.

Is there anything wrong with how I am using this module?  (extra code
removed for clarity)

 if tarfile.is_tarfile( file ):
try:
xf = tarfile.open( file, "r:gz" )
for locFile in xf:
logfile = xf.extractfile( locFile )
validFileFlag = True
# iterate through each log file, grab the first and
the last lines
lines = iter( logfile )
firstLine = lines.next()
for nextLine in lines:

continue

logfile.close()
 ...
xf.close()
except Exception, e:
validFileFlag = False
msg = "\nCould not open the log file: " + repr(file) + "
Exception: " + str(e) + "\n"
 else:
validFileFlag = False
lTime = extractFileNameTime( file )
msg = ">>> Warning " + file + " is NOT a valid tar archive
\n"
print msg

  
I haven't used tarfile, but this feels like a problem with the Win/Unix 
line endings.  I'm going to assume you're running on Windows, which 
could trigger the problem I'm going to describe.


You use 'file' to hold something, but don't show us what.  In fact, it's 
a lousy name, since it's already a Python builtin.  But if it's holding  
fileobj, that you've separately opened, then you need to change that 
open to use mode 'rb'


The problem, if I've guessed right, is that occasionally you'll 
accidentally encounter a 0d0a sequence in the middle of the (binary) 
compressed data.  If you're on Windows, and use the default 'r' mode, 
it'll be changed into a 0a byte.  Thus corrupting the checksum, and 
eventually the contents.


DaveA

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

Re: A question to experienced Pythoneers

[Lawrence D'Oliveiro]

In message
<8d1b76b7-1ba3-49c5-97cf-dc3837050...@y11g2000yqm.googlegroups.com>, Rony 
wrote:

> The manager of the development has been fired, main reason (what they
> told me) is that they have big big troubles in keeping deadlines ! For
> there last product, for which they estimated 3 man years of
> development they had 9 months extra effort, and the product was
> delivered a year to late.


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

Re: OpenCV_Problem

[Rami Chowdhury]

On Thu, Aug 19, 2010 at 13:47, arihant nahata  wrote:
> I m new to python and openCV. i installed openCV and python and copied the 
> necessary folder. and even appended the sys.path. but then too the same error.
>
> from opencv import cv
>
> File "C:\Python26\lib\site-packages\opencv\__init__.py", line 74, in
>
> 
>   from cv import *
> File "C:\Python26\lib\site-packages\opencv\cv.py", line 25, in 
>
 >  _cv = swig_import_helper()
 > File "C:\Python26\lib\site-packages\opencv\cv.py", line 21, in
> swig_import_helper
>_mod = imp.load_module('_cv', fp, pathname, description)
> ImportError: DLL load failed: The specified module could not be found.
>
> can you help me with this??
[next message]
> This is what i have,
>
> >>> print sys.path
>
> ['', 'C:\\Windows\\system32\\python27.zip', 'C:\\Python27\\DLLs',
> 'C:\\Python27\
> \lib', 'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk',
> 'C:\\Python27
> ', 'C:\\Python27\\lib\\site-packages',
> 'C:\\OpenCV2.0\\Python2.6\\Lib\\site-pack
> ages']
[next message]
>>There is no file named _cv.dll file in the directory that you mentioned
> what to do now.???

Well, we've established that the '_cv' module really isn't present.
Which makes me wonder if the OpenCV installation went correctly, or if
you've added the right paths. However, as I'm not an OpenCV expert, I
don't know where to look next.

If no one on the Python mailing list can help, you could also try the
OpenCV mailing list: http://tech.groups.yahoo.com/group/OpenCV/

HTH,
Rami

-- 
Rami Chowdhury
"Never assume malice when stupidity will suffice." -- Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[m_ahlenius]

On Aug 20, 5:34 am, Dave Angel  wrote:
> m_ahlenius wrote:
> > Hi,
>
> > I am relatively new to doing serious work in python.  I am using it to
> > access a large number of log files.  Some of the logs get corrupted
> > and I need to detect that when processing them.  This code seems to
> > work for quite a few of the logs (all same structure)  It also
> > correctly identifies some corrupt logs but then it identifies others
> > as being corrupt when they are not.
>
> > example error msg from below code:
>
> > Could not open the log file: '/disk/7-29-04-02-01.console.log.tar.gz'
> > Exception: CRC check\
> >  failed 0x8967e931 != 0x4e5f1036L
>
> > When I manually examine the supposed corrupt log file and use
> > "tar -xzvof /disk/7-29-04-02-01.console.log.tar.gz "  on it, it opens
> > just fine.
>
> > Is there anything wrong with how I am using this module?  (extra code
> > removed for clarity)
>
> >  if tarfile.is_tarfile( file ):
> >         try:
> >             xf = tarfile.open( file, "r:gz" )
> >             for locFile in xf:
> >                 logfile = xf.extractfile( locFile )
> >                 validFileFlag = True
> >                 # iterate through each log file, grab the first and
> > the last lines
> >                 lines = iter( logfile )
> >                 firstLine = lines.next()
> >                 for nextLine in lines:
> >                     
> >                         continue
>
> >                 logfile.close()
> >                  ...
> >             xf.close()
> >         except Exception, e:
> >             validFileFlag = False
> >             msg = "\nCould not open the log file: " + repr(file) + "
> > Exception: " + str(e) + "\n"
> >  else:
> >         validFileFlag = False
> >         lTime = extractFileNameTime( file )
> >         msg = ">>> Warning " + file + " is NOT a valid tar archive
> > \n"
> >         print msg
>
> I haven't used tarfile, but this feels like a problem with the Win/Unix
> line endings.  I'm going to assume you're running on Windows, which
> could trigger the problem I'm going to describe.
>
> You use 'file' to hold something, but don't show us what.  In fact, it's
> a lousy name, since it's already a Python builtin.  But if it's holding  
> fileobj, that you've separately opened, then you need to change that
> open to use mode 'rb'
>
> The problem, if I've guessed right, is that occasionally you'll
> accidentally encounter a 0d0a sequence in the middle of the (binary)
> compressed data.  If you're on Windows, and use the default 'r' mode,
> it'll be changed into a 0a byte.  Thus corrupting the checksum, and
> eventually the contents.
>
> DaveA

Hi,

thanks for the comments - I'll change the variable name.

I am running this on linux so don't think its a Windows issue.  So if
that's the case
is the 0d0a still an issue?

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

Re: A question to experienced Pythoneers

[Rami Chowdhury]

On Fri, Aug 20, 2010 at 15:25, geremy condra  wrote:
> On Fri, Aug 20, 2010 at 1:16 AM, Rony  wrote:
>> Here's the story :
>> I've been hired by a company as a consultant to reorganise there
>> development department.
[snip]
>> One of my plans is to introduce Python as development tool.
>> They mostly develop back-office software, and at the moment they do it
>> all in C with MFC.
>> Another new requirement they have, is that the new product should run
>> on Win & Mac.
[snip]
> 2) Use the tools at hand. If your developers don't know Python, you
> could wind up wasting a lot of talent turning a top-notch C developer
> into a bottom-tier Python developer, assuming you don't lose them
> altogether.
>
> 3) Don't rewrite critical code in a new language unless you have
> somebody who really knows what the hell they're doing. All you've done
> is turn programming's usual first-order ignorance into a much harder
> second-order problem.

+1 to both of these, personally. If the developers are used to C and
MFC, but you need to make the product run on the Mac as well, have you
considered C / C++ GUI frameworks like GTK, WxWidgets, or Qt? Porting
your GUI to those might be a better use of time than porting the
software to Python...


-- 
Rami Chowdhury
"Never assume malice when stupidity will suffice." -- Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 79 chars or more?

[Roy Smith]

In article <4c6dfb31$0$1$c3e8...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> Of course source code is written in a monospaced typeface, which is a 
> little wider and consequently fewer characters per page.

There was a fling a while ago with typesetting code in proportional 
spaced type.  I think some of the "Effective C++" series from 
Addison-Wesley did that.  Yuck.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Malcolm McLean]

On Aug 19, 2:14 pm, spinoza  wrote:
> All the rest [how to implement heaps] is
> detail for the little techies to normally, get wrong.
>
That's a fundamental feature of structured programming.

If we maintain the interface malloc(), realloc(), and free(), then we
could have a fairly simple or a fairly complicated scheme, and the
user doesn't care or need to know.

The problem is that a lot of techniques we can use to speed up memory
management, such as allocating from a stack, can't be used with this
interface. Designing good interfaces is hard.

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

Re: 79 chars or more?

[Neil Cerutti]

On 2010-08-20, Roy Smith  wrote:
> In article <4c6dfb31$0$1$c3e8...@news.astraweb.com>,
>  Steven D'Aprano  wrote:
>
>> Of course source code is written in a monospaced typeface, which is a 
>> little wider and consequently fewer characters per page.
>
> There was a fling a while ago with typesetting code in
> proportional spaced type.  I think some of the "Effective C++"
> series from Addison-Wesley did that.  Yuck.

It's probably influenced by The C++ Programming Language.
Stroustrup likes it.

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

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[m_ahlenius]

On Aug 20, 6:57 am, m_ahlenius  wrote:
> On Aug 20, 5:34 am, Dave Angel  wrote:
>
>
>
>
>
> > m_ahlenius wrote:
> > > Hi,
>
> > > I am relatively new to doing serious work in python.  I am using it to
> > > access a large number of log files.  Some of the logs get corrupted
> > > and I need to detect that when processing them.  This code seems to
> > > work for quite a few of the logs (all same structure)  It also
> > > correctly identifies some corrupt logs but then it identifies others
> > > as being corrupt when they are not.
>
> > > example error msg from below code:
>
> > > Could not open the log file: '/disk/7-29-04-02-01.console.log.tar.gz'
> > > Exception: CRC check\
> > >  failed 0x8967e931 != 0x4e5f1036L
>
> > > When I manually examine the supposed corrupt log file and use
> > > "tar -xzvof /disk/7-29-04-02-01.console.log.tar.gz "  on it, it opens
> > > just fine.
>
> > > Is there anything wrong with how I am using this module?  (extra code
> > > removed for clarity)
>
> > >  if tarfile.is_tarfile( file ):
> > >         try:
> > >             xf = tarfile.open( file, "r:gz" )
> > >             for locFile in xf:
> > >                 logfile = xf.extractfile( locFile )
> > >                 validFileFlag = True
> > >                 # iterate through each log file, grab the first and
> > > the last lines
> > >                 lines = iter( logfile )
> > >                 firstLine = lines.next()
> > >                 for nextLine in lines:
> > >                     
> > >                         continue
>
> > >                 logfile.close()
> > >                  ...
> > >             xf.close()
> > >         except Exception, e:
> > >             validFileFlag = False
> > >             msg = "\nCould not open the log file: " + repr(file) + "
> > > Exception: " + str(e) + "\n"
> > >  else:
> > >         validFileFlag = False
> > >         lTime = extractFileNameTime( file )
> > >         msg = ">>> Warning " + file + " is NOT a valid tar archive
> > > \n"
> > >         print msg
>
> > I haven't used tarfile, but this feels like a problem with the Win/Unix
> > line endings.  I'm going to assume you're running on Windows, which
> > could trigger the problem I'm going to describe.
>
> > You use 'file' to hold something, but don't show us what.  In fact, it's
> > a lousy name, since it's already a Python builtin.  But if it's holding  
> > fileobj, that you've separately opened, then you need to change that
> > open to use mode 'rb'
>
> > The problem, if I've guessed right, is that occasionally you'll
> > accidentally encounter a 0d0a sequence in the middle of the (binary)
> > compressed data.  If you're on Windows, and use the default 'r' mode,
> > it'll be changed into a 0a byte.  Thus corrupting the checksum, and
> > eventually the contents.
>
> > DaveA
>
> Hi,
>
> thanks for the comments - I'll change the variable name.
>
> I am running this on linux so don't think its a Windows issue.  So if
> that's the case
> is the 0d0a still an issue?
>
> 'mark

Oh and what's stored currently in
The file var us just the unopened pathname to the
Target file I want to open

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

Get authentication error while using 'smtplib'

[Mahmood Naderan]

I have this script to send an email via SMTP:
import smtplib
smtpserver = 'smtp.server.com'
AUTHREQUIRED = 1# if you need to use SMTP AUTH set to 1
smtpuser = "username"# for SMTP AUTH, set SMTP username here
smtppass = "password"# for SMTP AUTH, set SMTP password here
RECIPIENTS ='recipi...@server.com'
SENDER = 'sen...@server.com'
mssg = open('filename.txt', 'r').read()
session = smtplib.SMTP(smtpserver)
if AUTHREQUIRED:
   session.login(smtpuser, smtppass)
smtpresult = session.sendmail(SENDER, RECIPIENTS, mssg)
After running the script I get this error:
 
Traceback (most recent call last):
  File "my_mail.py", line 14, in 
    session.login(smtpuser, smtppass)
  File "/usr/lib/python2.6/smtplib.py", line 589, in login
    raise SMTPAuthenticationError(code, resp)
smtplib.SMTPAuthenticationError: (535, '5.7.0 Error: authentication failed: 
authentication failure')

However there is no problem with my user/pass because I can login to my mail 
account.

Thanks for any idea. 
// Naderan *Mahmood; 


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

Re: A question to experienced Pythoneers

[Stefan Schwarzer]

Hi Lawrence,

On 2010-08-20 13:11, Lawrence D'Oliveiro wrote:
> In message
> <8d1b76b7-1ba3-49c5-97cf-dc3837050...@y11g2000yqm.googlegroups.com>, Rony
> wrote:
>
>> The manager of the development has been fired, main reason (what they
>> told me) is that they have big big troubles in keeping deadlines ! For
>> there last product, for which they estimated 3 man years of
>> development they had 9 months extra effort, and the product was
>> delivered a year to late.
>
> 

I can't get the page; all I get is an error message:

"""
Not Found

The requested message, i4ku71$fd...@lust.ihug.co.nz, could not be found.
"""

Can you please give a part of the message to search for or
even better, an URL that works? :-)

Thanks,
Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 79 chars or more?

[Bruno Desthuilliers]

Stefan Schwarzer a écrit :

Hi Neil,

On 2010-08-17 14:42, Neil Cerutti wrote:

(snip)

Looking through my code, the split-up lines almost always include
string literals or elimination of meaningless temporary
variables, e.g.:

self.expiration_date = translate_date(find(response,
'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y')


I'd probably reformat this to

  self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d', '%m%d%Y')

or even

  self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d',
'%m%d%Y')



make this :

   self.expiration_date = translate_date(
   find(response, 'MPNExpirationDate').text,
   '%Y-%m-%d',
   '%m%d%Y'
   )

I just HATE closing parens on the same line when the args don't fit on 
one single line.



Significant indentation only solves one single issue when it comes to 
coding conventions war !-)

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

Re: 79 chars or more?

[Neil Cerutti]

On 2010-08-20, Bruno Desthuilliers  
wrote:
> make this :
>
> self.expiration_date = translate_date(
> find(response, 'MPNExpirationDate').text,
> '%Y-%m-%d',
> '%m%d%Y'
> )
>
> I just HATE closing parens on the same line when the args don't
> fit on one single line.

It's been interesting to see my code scrutinized like this.
Thanks all. As a result of the discussion, I changed
translate_date to trans_date_from_to to make the order of
arguments clear.

find is just a small wrapper around Element.find calls, inserting
the namespace.

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

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[Dave Angel]

m_ahlenius wrote:

On Aug 20, 6:57 am, m_ahlenius  wrote:
  

On Aug 20, 5:34 am, Dave Angel  wrote:







m_ahlenius wrote:
  

Hi,

I am relatively new to doing serious work in python.  I am using it to

access a large number of log files.  Some of the logs get corrupted
and I need to detect that when processing them.  This code seems to
work for quite a few of the logs (all same structure)  It also
correctly identifies some corrupt logs but then it identifies others
as being corrupt when they are not.

example error msg from below code:

Could not open the log file: '/disk/7-29-04-02-01.console.log.tar.gz'

Exception: CRC check\
 failed 0x8967e931 !=x4e5f1036L

When I manually examine the supposed corrupt log file and use

"tar -xzvof /disk/7-29-04-02-01.console.log.tar.gz "  on it, it opens
just fine.

Is there anything wrong with how I am using this module?  (extra code

removed for clarity)

 if tarfile.is_tarfile( file ):

try:
xf =arfile.open( file, "r:gz" )
for locFile in xf:
logfile =f.extractfile( locFile )
validFileFlag =rue
# iterate through each log file, grab the first and
the last lines
lines =ter( logfile )
firstLine =ines.next()
for nextLine in lines:

continue

logfile.close()

 ...
xf.close()
except Exception, e:
validFileFlag =alse
msg =\nCould not open the log file: " + repr(file) + "
Exception: " + str(e) + "\n"
 else:
validFileFlag =alse
lTime =xtractFileNameTime( file )
msg =>>> Warning " + file + " is NOT a valid tar archive
\n"
print msg


I haven't used tarfile, but this feels like a problem with the Win/Unix
line endings.  I'm going to assume you're running on Windows, which
could trigger the problem I'm going to describe.
  
You use 'file' to hold something, but don't show us what.  In fact, it's
a lousy name, since it's already a Python builtin.  But if it's holding  
fileobj, that you've separately opened, then you need to change that

open to use mode 'rb'
  
The problem, if I've guessed right, is that occasionally you'll

accidentally encounter a 0d0a sequence in the middle of the (binary)
compressed data.  If you're on Windows, and use the default 'r' mode,
it'll be changed into a 0a byte.  Thus corrupting the checksum, and
eventually the contents.
  
DaveA
  

Hi,

thanks for the comments - I'll change the variable name.

I am running this on linux so don't think its a Windows issue.  So if
that's the case
is the 0d0a still an issue?

'mark



Oh and what's stored currently in
The file var us just the unopened pathname to the
Target file I want to open


  
No, on Linux, there should be no such problem.  And I have to assume 
that if you pass the filename as a string, the library would use 'rb' 
anyway.  It's just if you pass a fileobj,  AND are on Windows.


Sorry I wasted your time, but nobody else had answered, and I hoped it 
might help.


DaveA

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

Re: A question to experienced Pythoneers

[Stefan Schwarzer]

Hi Rony,

On 2010-08-20 10:16, Rony wrote:
> Here's the story :
> I've been hired by a company as a consultant to reorganise there
> development department.
> The actual situation is :
> The manager of the development has been fired, main reason (what they
> told me) is that they have big big troubles in keeping deadlines ! For
> there last product, for which they estimated 3 man years of
> development they had 9 months extra effort, and the product was
> delivered a year to late.

I guess the most important issue will be to find out what
was wrong with the development process and fix the problems,
i. e. don't repeat them. Keep in mind that "what was wrong"
can mean any number of reasons.

Until you haven't dealt with this, thinking about changing
the programming language in my opinion makes little sense.

> I basicaly have 'carte blanche' :)

Um, yes ... with the corresponding responsibilities and
risks. :-)

> So, my strategie would be :
> - Use Python and wxpython for the GUI
> - Develop critical routines in Pyrex or in C and make PYD's from it
> which will be imported by the main Python programm.
> - Distribute with py2exe on Win & py2app for Mac.

You plan to change a process (and people) used to developing
with C to developing with Python and the associated tools.
For a developer experienced with both C and Python, using
the latter usually will result in faster development. On the
other hand, switching to a tool you (i. e. an individual
developer) never used before adds some risk (-> uncertainty
in effort estimation).

If the project you're dealing with now is based on the
project you mentioned above, you better not start from
scratch in a different language. Very likely the existing
code will have subtle though important fixes for subtle
problems which were encountered during development. If you
start from scratch you risk losing these fixes and having to
re-discover the problems and fixes which can take a lot of
time. Even if you have all programmers of the old team
available, it's risky because they might have forgotten the
parts of the code or they may no longer be around when
you're about to implement the functionality of these
critical parts of the code.

If you haven't already, I recommend to read these books:

Steve McConnell
Rapid Development
http://www.amazon.com/x/dp/0072850604/

Tom DeMarco, Timothy Lister
Waltzing With Bears: Managing Risk on Software Projects
http://www.amazon.com/x/dp/0932633609/

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

Re: Reading the access attributes of directories in Windows

[vsoler]

On Aug 20, 9:36 am, Tim Golden  wrote:
> > I currently do not have subversion access in my PC. I could try to
> > install a free copy of it. But it you could ptovide an installer, it
> > certainly would do things easier. Please let me know if it is
> > possible.
>
> Vicente, can you just confirm that you received the installer I
> sent offlist? I'll try to put winsys on PyPI with installers;
> just haven't got round to it yes :)
>
> TJG

Tim,

I just downloaded it, and am going to install it right away.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[Peter Otten]

m_ahlenius wrote:

> On Aug 20, 6:57 am, m_ahlenius  wrote:
>> On Aug 20, 5:34 am, Dave Angel  wrote:
>>
>>
>>
>>
>>
>> > m_ahlenius wrote:
>> > > Hi,
>>
>> > > I am relatively new to doing serious work in python.  I am using it
>> > > to access a large number of log files.  Some of the logs get
>> > > corrupted and I need to detect that when processing them.  This code
>> > > seems to work for quite a few of the logs (all same structure)  It
>> > > also correctly identifies some corrupt logs but then it identifies
>> > > others as being corrupt when they are not.
>>
>> > > example error msg from below code:
>>
>> > > Could not open the log file: '/disk/7-29-04-02-01.console.log.tar.gz'
>> > > Exception: CRC check\
>> > > failed 0x8967e931 != 0x4e5f1036L
>>
>> > > When I manually examine the supposed corrupt log file and use
>> > > "tar -xzvof /disk/7-29-04-02-01.console.log.tar.gz "  on it, it opens
>> > > just fine.
>>
>> > > Is there anything wrong with how I am using this module?  (extra code
>> > > removed for clarity)
>>
>> > > if tarfile.is_tarfile( file ):
>> > > try:
>> > > xf = tarfile.open( file, "r:gz" )
>> > > for locFile in xf:
>> > > logfile = xf.extractfile( locFile )
>> > > validFileFlag = True
>> > > # iterate through each log file, grab the first and
>> > > the last lines
>> > > lines = iter( logfile )
>> > > firstLine = lines.next()
>> > > for nextLine in lines:
>> > > 
>> > > continue
>>
>> > > logfile.close()
>> > > ...
>> > > xf.close()
>> > > except Exception, e:
>> > > validFileFlag = False
>> > > msg = "\nCould not open the log file: " + repr(file) + "
>> > > Exception: " + str(e) + "\n"
>> > > else:
>> > > validFileFlag = False
>> > > lTime = extractFileNameTime( file )
>> > > msg = ">>> Warning " + file + " is NOT a valid tar archive
>> > > \n"
>> > > print msg
>>
>> > I haven't used tarfile, but this feels like a problem with the Win/Unix
>> > line endings.  I'm going to assume you're running on Windows, which
>> > could trigger the problem I'm going to describe.
>>
>> > You use 'file' to hold something, but don't show us what.  In fact,
>> > it's a lousy name, since it's already a Python builtin.  But if it's
>> > holding fileobj, that you've separately opened, then you need to change
>> > that open to use mode 'rb'
>>
>> > The problem, if I've guessed right, is that occasionally you'll
>> > accidentally encounter a 0d0a sequence in the middle of the (binary)
>> > compressed data.  If you're on Windows, and use the default 'r' mode,
>> > it'll be changed into a 0a byte.  Thus corrupting the checksum, and
>> > eventually the contents.
>>
>> > DaveA
>>
>> Hi,
>>
>> thanks for the comments - I'll change the variable name.
>>
>> I am running this on linux so don't think its a Windows issue.  So if
>> that's the case
>> is the 0d0a still an issue?
>>
>> 'mark
> 
> Oh and what's stored currently in
> The file var us just the unopened pathname to the
> Target file I want to open

Random questions:

What python version are you using?
If you have other python versions around, do they exhibit the same problem?
If you extract and compress your data using the external tool, does the 
resulting file make problems in Python, too?
If so, can you reduce data size and put a small demo online for others to 
experiment with?

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

Re: A question to experienced Pythoneers

[Rony]

It looks like I forgot to specify that the product is a totaly new
product build from scratch, not an upgrade from an existing product.

Interesting answers !

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

Re: Reading the access attributes of directories in Windows

[vsoler]

On Aug 20, 9:36 am, Tim Golden  wrote:
> > I currently do not have subversion access in my PC. I could try to
> > install a free copy of it. But it you could ptovide an installer, it
> > certainly would do things easier. Please let me know if it is
> > possible.
>
> Vicente, can you just confirm that you received the installer I
> sent offlist? I'll try to put winsys on PyPI with installers;
> just haven't got round to it yes :)
>
> TJG

Tim,

I just downloaded it, and am going to install it right away.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reading the access attributes of directories in Windows

[vsoler]

On Aug 20, 4:26 pm, vsoler  wrote:
> On Aug 20, 9:36 am, Tim Golden  wrote:
>
> > > I currently do not have subversion access in my PC. I could try to
> > > install a free copy of it. But it you could ptovide an installer, it
> > > certainly would do things easier. Please let me know if it is
> > > possible.
>
> > Vicente, can you just confirm that you received the installer I
> > sent offlist? I'll try to put winsys on PyPI with installers;
> > just haven't got round to it yes :)
>
> > TJG
>
> Tim,
>
> I just downloaded it, and am going to install it right away.

Tim,

It works!!! or at least, should I say, it runs!!! wonderful.

Now, would it be possible to have a hint/suggestion as to some lines
that I should include in my script?

I find this exercice very interesting.

Thank you for your help.

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

Re: Looking for an appropriate encoding standard that supports all languages

[ata.jaf]

On Aug 19, 11:48 am, Steven D'Aprano  wrote:
> On Thu, 19 Aug 2010 01:29:51 -0700, ata.jaf wrote:
> > On Aug 17, 11:55 pm, Thomas Jollans  wrote:
> >> On Tuesday 17 August 2010, it occurred to ata.jaf to exclaim:
>
> >> > I am developing a little program in Mac with wxPython. But I have
> >> > problems with the characters that are not in ASCII. Like some special
> >> > characters in French or Turkish. So I am looking for a way to solve
> >> > this. Like an encoding standard that supports all languages. Or some
> >> > other way.
>
> >> Anything that supports all of Unicode will do. Like UTF-8. If your text
> >> is mostly Latin, then just go for UTF-8, if you use other alphabets
> >> extensively, you might want to consider UTF-16, which might the use a
> >> little less space.
>
> > OK, I used UTF-8.
> > I write a line of strings in the source code
>
> Do you have a source code encoding line at the start of your script?
>
> http://www.python.org/dev/peps/pep-0263/
>
> > and I want my program to
> > show that as an output on GUI. And this line of strings includes a
> > character like "ü". But I see that in GUI this character is replaced
> > with another strange characters. I mean it doesn't work. And when I try
> > to use UTF-16, I get an syntax error that declares "UTF-16 stream does
> > not start with BOM".
>
> What GUI are you using?
>
> Please COPY AND PASTE (do not retype) the EXACT error message you get,
> including the entire traceback.
>
> --
> Steven

Yes I have a source code encoding line.
Here it is:


# -*- coding: utf_16 -*-


I am using WxPython.

And the error that I get about using utf-16 is:\



Traceback (most recent call last):
  File "", line 1, in 
  File "z.py", line 2
SyntaxError: UTF-16 stream does not start with BOM
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reading the access attributes of directories in Windows

[Tim Golden]

On 20/08/2010 15:49, vsoler wrote:

On Aug 20, 4:26 pm, vsoler  wrote:

On Aug 20, 9:36 am, Tim Golden  wrote:


I currently do not have subversion access in my PC. I could try to
install a free copy of it. But it you could ptovide an installer, it
certainly would do things easier. Please let me know if it is
possible.



Vicente, can you just confirm that you received the installer I
sent offlist? I'll try to put winsys on PyPI with installers;
just haven't got round to it yes :)



TJG


Tim,

I just downloaded it, and am going to install it right away.


Tim,

It works!!! or at least, should I say, it runs!!! wonderful.

Now, would it be possible to have a hint/suggestion as to some lines
that I should include in my script?


Depends what, exactly, you want your script to do :)

The simplest way to get an ad-hoc look at what permissions are applied to
a file is:


import os, sys
from winsys import fs

#
# Just using sys.executable as a file I know will exist;
# obviously you put your own file name in there...
#
fs.file (sys.executable).security ().dump ()



To get that in the more compact but more esoteric MS SDDL format:


import os, sys
from winsys import fs

print (fs.file (sys.executable).security ())



To decode the permission bit-strings to vaguely meaningful
names:


import os, sys
from winsys import fs

dacl = fs.file (sys.executable).security ().dacl
for permission in dacl:
  print (d.trustee, " (Inherited )" if d.inherited else "")
  for name in fs.FILE_ACCESS.names_from_value (d.access):
print ("  ", name)



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

Re: A question to experienced Pythoneers

[Bruno Desthuilliers]

Rony a écrit :

It looks like I forgot to specify that the product is a totaly new
product build from scratch, not an upgrade from an existing product.



Still the advice to first find out what went wrong with the previous 
project is a very sensible one. Technical problems do exist, but from 
experience they rarely are the main source of failure.

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

Re: Iterative vs. Recursive coding

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

On Thu, 19 Aug 2010 22:00:16 +, Martin Gregorie wrote:


Recursion can be quite a trick to get your mind round at first


Really? Do people actually find the *concept* of recursion to be tricky?



I onced worked in a shop (Win32 desktop / accouting applications mainly) 
where I was the only guy that could actually understand recursion. FWIW, 
I also was the only guy around that understood "hairy" (lol) concepts 
like callback functions, FSM, polymorphism, hashtables, linked lists, 
ADTs, algorithm complexity etc...


Needless to say, I didn't last long !-)

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

Re: Iterative vs. Recursive coding

[Michel Claveau - MVP]

Salut ! 

C'est cela, la solitude du programmeur génial...

@-salutations
-- 
Michel Claveau 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: urllib "quote" problem

[Aahz]

In article <4c5eef7f$0$1609$742ec...@news.sonic.net>,
John Nagle   wrote:
>
> This looks like code that will do the wrong thing in
>Python 2.6 for characters in the range 128-255.  Those are
>illegal in type "str", but this code is constructing such
>values with "chr".

WDYM "illegal"?
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"...if I were on life-support, I'd rather have it run by a Gameboy than a
Windows box."  --Cliff Wells
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Iterative vs. Recursive coding

[Bruno Desthuilliers]

Michel Claveau - MVP a écrit :
Salut ! 


C'est cela, la solitude du programmeur génial...

@-salutations


Moi aussi je t'aime, Michel !-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: requirements in writing an email/rss/usenet client?

[Aahz]

In article ,
George Oliver   wrote:
>
>I'd like to know what to consider when writing an email/rss/usenet
>client. Apologies for such a broad question, but I've never attempted
>a project of this scope and I'm currently feeling out the
>requirements.

About the only advice I can give you to such a broad question is the
aphorism "Be strict about what you send; be generous about what you
receive".  IOW, follow the standards very very carefully in sending
messages but be very very lenient with what you accept (just make sure
you don't crash).

Overall, you probably will get discouraged eventually, so I suggest that
you try to have as much fun as possible along the way.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"...if I were on life-support, I'd rather have it run by a Gameboy than a
Windows box."  --Cliff Wells
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A question to experienced Pythoneers

[Aahz]

In article <8d1b76b7-1ba3-49c5-97cf-dc3837050...@y11g2000yqm.googlegroups.com>,
Rony   wrote:
>
>The manager of the development has been fired, main reason (what they
>told me) is that they have big big troubles in keeping deadlines ! For
>there last product, for which they estimated 3 man years of
>development they had 9 months extra effort, and the product was
>delivered a year to late.

Keep in mind that the real problem may have been that upper management
forced a completely unrealistic deadline.  They may also have had
difficulty translating "development effort" into Real World Timing [tm].
(For example, when I tell my boss that something will take three days of
development effort, I also make clear that between support and production
issues that I need to help with, not to mention meetings, mentoring other
people on my team, etc -- those three days will almost inevitably expand
into six business days BEST CASE.)

Try to have some quiet, off-campus discussions with developers to gather
information.

NOTE VERY CAREFULLY: if you promise to keep a conversation private, KEEP
THE PROMISE.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"...if I were on life-support, I'd rather have it run by a Gameboy than a
Windows box."  --Cliff Wells
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reading the access attributes of directories in Windows

[vsoler]

On Aug 20, 5:10 pm, Tim Golden  wrote:
> On 20/08/2010 15:49, vsoler wrote:
>
>
>
> > On Aug 20, 4:26 pm, vsoler  wrote:
> >> On Aug 20, 9:36 am, Tim Golden  wrote:
>
>  I currently do not have subversion access in my PC. I could try to
>  install a free copy of it. But it you could ptovide an installer, it
>  certainly would do things easier. Please let me know if it is
>  possible.
>
> >>> Vicente, can you just confirm that you received the installer I
> >>> sent offlist? I'll try to put winsys on PyPI with installers;
> >>> just haven't got round to it yes :)
>
> >>> TJG
>
> >> Tim,
>
> >> I just downloaded it, and am going to install it right away.
>
> > Tim,
>
> > It works!!! or at least, should I say, it runs!!! wonderful.
>
> > Now, would it be possible to have a hint/suggestion as to some lines
> > that I should include in my script?
>
> Depends what, exactly, you want your script to do :)
>
> The simplest way to get an ad-hoc look at what permissions are applied to
> a file is:
>
> 
> import os, sys
> from winsys import fs
>
> #
> # Just using sys.executable as a file I know will exist;
> # obviously you put your own file name in there...
> #
> fs.file (sys.executable).security ().dump ()
>
> 
>
> To get that in the more compact but more esoteric MS SDDL format:
>
> 
> import os, sys
> from winsys import fs
>
> print (fs.file (sys.executable).security ())
>
> 
>
> To decode the permission bit-strings to vaguely meaningful
> names:
>
> 
> import os, sys
> from winsys import fs
>
> dacl = fs.file (sys.executable).security ().dacl
> for permission in dacl:
>    print (d.trustee, " (Inherited )" if d.inherited else "")
>    for name in fs.FILE_ACCESS.names_from_value (d.access):
>      print ("  ", name)
>
> 
>
> TJG

Tim,

in your last piece of code, the definition of "d" is missing. missed
anything when copying?

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

Re: Looking for an appropriate encoding standard that supports all languages

[Rami Chowdhury]

On Fri, Aug 20, 2010 at 21:02, ata.jaf  wrote:
> On Aug 19, 11:48 am, Steven D'Aprano  t...@cybersource.com.au> wrote:
>> On Thu, 19 Aug 2010 01:29:51 -0700, ata.jaf wrote:
>> > On Aug 17, 11:55 pm, Thomas Jollans  wrote:
>> >> On Tuesday 17 August 2010, it occurred to ata.jaf to exclaim:
>>
>> >> > I am developing a little program in Mac with wxPython. But I have
>> >> > problems with the characters that are not in ASCII. Like some special
>> >> > characters in French or Turkish. So I am looking for a way to solve
>> >> > this. Like an encoding standard that supports all languages. Or some
>> >> > other way.
>>
>> >> Anything that supports all of Unicode will do. Like UTF-8. If your text
>> >> is mostly Latin, then just go for UTF-8, if you use other alphabets
>> >> extensively, you might want to consider UTF-16, which might the use a
>> >> little less space.
>>
>> > OK, I used UTF-8.
>> > I write a line of strings in the source code
>>
>> Do you have a source code encoding line at the start of your script?
>>
>> http://www.python.org/dev/peps/pep-0263/
>>
>
> Yes I have a source code encoding line.
> Here it is:
>
> # -*- coding: utf_16 -*-
>
> I am using WxPython.
>
> And the error that I get about using utf-16 is:\
>
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "z.py", line 2
> SyntaxError: UTF-16 stream does not start with BOM

Which encoding are you saving your script in? Very few of the text
editors I've used save to UTF-16 by default.

-- 
Rami Chowdhury
"Never assume malice when stupidity will suffice." -- Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reading the access attributes of directories in Windows

[vsoler]

On Aug 20, 5:10 pm, Tim Golden  wrote:
> On 20/08/2010 15:49, vsoler wrote:
>
>
>
> > On Aug 20, 4:26 pm, vsoler  wrote:
> >> On Aug 20, 9:36 am, Tim Golden  wrote:
>
>  I currently do not have subversion access in my PC. I could try to
>  install a free copy of it. But it you could ptovide an installer, it
>  certainly would do things easier. Please let me know if it is
>  possible.
>
> >>> Vicente, can you just confirm that you received the installer I
> >>> sent offlist? I'll try to put winsys on PyPI with installers;
> >>> just haven't got round to it yes :)
>
> >>> TJG
>
> >> Tim,
>
> >> I just downloaded it, and am going to install it right away.
>
> > Tim,
>
> > It works!!! or at least, should I say, it runs!!! wonderful.
>
> > Now, would it be possible to have a hint/suggestion as to some lines
> > that I should include in my script?
>
> Depends what, exactly, you want your script to do :)
>
> The simplest way to get an ad-hoc look at what permissions are applied to
> a file is:
>
> 
> import os, sys
> from winsys import fs
>
> #
> # Just using sys.executable as a file I know will exist;
> # obviously you put your own file name in there...
> #
> fs.file (sys.executable).security ().dump ()
>
> 
>
> To get that in the more compact but more esoteric MS SDDL format:
>
> 
> import os, sys
> from winsys import fs
>
> print (fs.file (sys.executable).security ())
>
> 
>
> To decode the permission bit-strings to vaguely meaningful
> names:
>
> 
> import os, sys
> from winsys import fs
>
> dacl = fs.file (sys.executable).security ().dacl
> for permission in dacl:
>    print (d.trustee, " (Inherited )" if d.inherited else "")
>    for name in fs.FILE_ACCESS.names_from_value (d.access):
>      print ("  ", name)
>
> 
>
> TJG

it seems as though the definition of "d" is missing in your last piece
of code
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[m_ahlenius]

On Aug 20, 9:10 am, Dave Angel  wrote:
> m_ahlenius wrote:
> > On Aug 20, 6:57 am, m_ahlenius  wrote:
>
> >> On Aug 20, 5:34 am, Dave Angel  wrote:
>
> >>> m_ahlenius wrote:
>
>  Hi,
>
>  I am relatively new to doing serious work in python.  I am using it to
>  access a large number of log files.  Some of the logs get corrupted
>  and I need to detect that when processing them.  This code seems to
>  work for quite a few of the logs (all same structure)  It also
>  correctly identifies some corrupt logs but then it identifies others
>  as being corrupt when they are not.
>
>  example error msg from below code:
>
>  Could not open the log file: '/disk/7-29-04-02-01.console.log.tar.gz'
>  Exception: CRC check\
>   failed 0x8967e931 !=x4e5f1036L
>
>  When I manually examine the supposed corrupt log file and use
>  "tar -xzvof /disk/7-29-04-02-01.console.log.tar.gz "  on it, it opens
>  just fine.
>
>  Is there anything wrong with how I am using this module?  (extra code
>  removed for clarity)
>
>   if tarfile.is_tarfile( file ):
>          try:
>              xf =arfile.open( file, "r:gz" )
>              for locFile in xf:
>                  logfile =f.extractfile( locFile )
>                  validFileFlag =rue
>                  # iterate through each log file, grab the first and
>  the last lines
>                  lines =ter( logfile )
>                  firstLine =ines.next()
>                  for nextLine in lines:
>                      
>                          continue
>
>                  logfile.close()
>                   ...
>              xf.close()
>          except Exception, e:
>              validFileFlag =alse
>              msg =\nCould not open the log file: " + repr(file) + "
>  Exception: " + str(e) + "\n"
>   else:
>          validFileFlag =alse
>          lTime =xtractFileNameTime( file )
>          msg =>>> Warning " + file + " is NOT a valid tar archive
>  \n"
>          print msg
>
> >>> I haven't used tarfile, but this feels like a problem with the Win/Unix
> >>> line endings.  I'm going to assume you're running on Windows, which
> >>> could trigger the problem I'm going to describe.
>
> >>> You use 'file' to hold something, but don't show us what.  In fact, it's
> >>> a lousy name, since it's already a Python builtin.  But if it's holding  
> >>> fileobj, that you've separately opened, then you need to change that
> >>> open to use mode 'rb'
>
> >>> The problem, if I've guessed right, is that occasionally you'll
> >>> accidentally encounter a 0d0a sequence in the middle of the (binary)
> >>> compressed data.  If you're on Windows, and use the default 'r' mode,
> >>> it'll be changed into a 0a byte.  Thus corrupting the checksum, and
> >>> eventually the contents.
>
> >>> DaveA
>
> >> Hi,
>
> >> thanks for the comments - I'll change the variable name.
>
> >> I am running this on linux so don't think its a Windows issue.  So if
> >> that's the case
> >> is the 0d0a still an issue?
>
> >> 'mark
>
> > Oh and what's stored currently in
> > The file var us just the unopened pathname to the
> > Target file I want to open
>
> No, on Linux, there should be no such problem.  And I have to assume
> that if you pass the filename as a string, the library would use 'rb'
> anyway.  It's just if you pass a fileobj,  AND are on Windows.
>
> Sorry I wasted your time, but nobody else had answered, and I hoped it
> might help.
>
> DaveA

Hi Dave

thanks for responding - you were not wasting my time but helping me to
be aware of other potential issues.

Appreciate it much.

Its just weird that it works for most files and even finds corrupt
ones, but some of the ones it marks as corrupt seem to be OK.

thanks

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

Re: Iterative vs. Recursive coding

[John Nagle]

On 8/20/2010 12:47 AM, News123 wrote:

On 08/20/2010 02:26 AM, Steven D'Aprano wrote:

On Thu, 19 Aug 2010 22:00:16 +, Martin Gregorie wrote:


Recursion can be quite a trick to get your mind round at first


Really? Do people actually find the *concept* of recursion to be tricky?

Is this a sincere surprise or are you just boasting?


If I remember correctly, my puzzlement about recursion lasted about 15
seconds. I remember thinking "How does the function foo know that there
is a function foo when foo doesn't fully exist yet?", but once I accepted
the fact that it just does it all just seemed obvious. Getting recursion
*right* is sometimes tricky, but the idea itself isn't.


If you think about what the implementation has to do, it's quite
complicated.  Which objects are copied, and which are merely
referenced?  Is the recursion going to result in control being
inside the same object instance twice?  Is the recursion a closure?
Is tail recursion possible, and does your language implement it?

Python does not do tail recursion, so using recursion
where iteration could do the job is generally a bad idea.  Scheme, on
the other hand, always does tail recursion where possible.

Python does have generators, and I recently wrote a recursive
generator for a production application.  I needed to descend a
specialized directory tree structure (the one used by the US
Securities and Exchange Commission to store filings) and
retrieve the last N days of filings.  So I have a recursive
generator that returns directory after directory, descending
into the directories for years and quarters as necessary.
The calling function stops calling the generator when it
has found the information it needs, which happens before
the generator runs out.  That's a real-life use case
for such a construct, and led to much shorter code than
a non-recursive implementation.

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

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[m_ahlenius]

On Aug 20, 9:25 am, Peter Otten <__pete...@web.de> wrote:
> m_ahlenius wrote:
> > On Aug 20, 6:57 am, m_ahlenius  wrote:
> >> On Aug 20, 5:34 am, Dave Angel  wrote:
>
> >> > m_ahlenius wrote:
> >> > > Hi,
>
> >> > > I am relatively new to doing serious work in python.  I am using it
> >> > > to access a large number of log files.  Some of the logs get
> >> > > corrupted and I need to detect that when processing them.  This code
> >> > > seems to work for quite a few of the logs (all same structure)  It
> >> > > also correctly identifies some corrupt logs but then it identifies
> >> > > others as being corrupt when they are not.
>
> >> > > example error msg from below code:
>
> >> > > Could not open the log file: '/disk/7-29-04-02-01.console.log.tar.gz'
> >> > > Exception: CRC check\
> >> > > failed 0x8967e931 != 0x4e5f1036L
>
> >> > > When I manually examine the supposed corrupt log file and use
> >> > > "tar -xzvof /disk/7-29-04-02-01.console.log.tar.gz "  on it, it opens
> >> > > just fine.
>
> >> > > Is there anything wrong with how I am using this module?  (extra code
> >> > > removed for clarity)
>
> >> > > if tarfile.is_tarfile( file ):
> >> > > try:
> >> > > xf = tarfile.open( file, "r:gz" )
> >> > > for locFile in xf:
> >> > > logfile = xf.extractfile( locFile )
> >> > > validFileFlag = True
> >> > > # iterate through each log file, grab the first and
> >> > > the last lines
> >> > > lines = iter( logfile )
> >> > > firstLine = lines.next()
> >> > > for nextLine in lines:
> >> > > 
> >> > > continue
>
> >> > > logfile.close()
> >> > > ...
> >> > > xf.close()
> >> > > except Exception, e:
> >> > > validFileFlag = False
> >> > > msg = "\nCould not open the log file: " + repr(file) + "
> >> > > Exception: " + str(e) + "\n"
> >> > > else:
> >> > > validFileFlag = False
> >> > > lTime = extractFileNameTime( file )
> >> > > msg = ">>> Warning " + file + " is NOT a valid tar archive
> >> > > \n"
> >> > > print msg
>
> >> > I haven't used tarfile, but this feels like a problem with the Win/Unix
> >> > line endings.  I'm going to assume you're running on Windows, which
> >> > could trigger the problem I'm going to describe.
>
> >> > You use 'file' to hold something, but don't show us what.  In fact,
> >> > it's a lousy name, since it's already a Python builtin.  But if it's
> >> > holding fileobj, that you've separately opened, then you need to change
> >> > that open to use mode 'rb'
>
> >> > The problem, if I've guessed right, is that occasionally you'll
> >> > accidentally encounter a 0d0a sequence in the middle of the (binary)
> >> > compressed data.  If you're on Windows, and use the default 'r' mode,
> >> > it'll be changed into a 0a byte.  Thus corrupting the checksum, and
> >> > eventually the contents.
>
> >> > DaveA
>
> >> Hi,
>
> >> thanks for the comments - I'll change the variable name.
>
> >> I am running this on linux so don't think its a Windows issue.  So if
> >> that's the case
> >> is the 0d0a still an issue?
>
> >> 'mark
>
> > Oh and what's stored currently in
> > The file var us just the unopened pathname to the
> > Target file I want to open
>
> Random questions:
>
> What python version are you using?
> If you have other python versions around, do they exhibit the same problem?
> If you extract and compress your data using the external tool, does the
> resulting file make problems in Python, too?
> If so, can you reduce data size and put a small demo online for others to
> experiment with?
>
> Peter

Hi,

I am using Python 2.6.5.

Unfortunately I don't have other versions installed so its hard to
test with a different version.

As for the log compression, its a bit hard to test.  Right now I may
process 100+ of these logs per night, and will get maybe 5 which are
reported as corrupt (typically a bad CRC) and 2 which it reported as a
bad tar archive.  This morning I checked each of the 7 reported
problem files by manually opening them with "tar -xzvof" and they were
all indeed corrupt. Sign.

Unfortunately due to the nature of our business, I can't post the data
files online, I hope you can understand.  But I really appreciate your
suggestions.

The thing that gets me is that it seems to work just fine for most
files, but then not others.  Labeling normal files as corrupt hurts us
as we then skip getting any log data from those files.

appreciate all your help.

'mark

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

Re: Iterative vs. Recursive coding

[Neil Cerutti]

On 2010-08-20, John Nagle  wrote:
> Python does not do tail recursion, so using recursion where
> iteration could do the job is generally a bad idea.  Scheme, on
> the other hand, always does tail recursion where possible.

A tail-recursive function is usually easy to convert to a
loop-style iteration. However, Scheme does tail-call
optimization, I believe, which is slightly more general.

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

Re: Reading the access attributes of directories in Windows

[Tim Golden]

On 20/08/2010 5:10 PM, vsoler wrote:

On Aug 20, 5:10 pm, Tim Golden  wrote:

To decode the permission bit-strings to vaguely meaningful
names:


import os, sys
from winsys import fs

dacl = fs.file (sys.executable).security ().dacl
for permission in dacl:
print (d.trustee, " (Inherited )" if d.inherited else "")
for name in fs.FILE_ACCESS.names_from_value (d.access):
  print ("  ", name)



TJG


it seems as though the definition of "d" is missing in your last piece
of code



Whoops, changed tack mid-thingy. Try:

dacl = ...
for d in dacl:
  # .. as before
--
http://mail.python.org/mailman/listinfo/python-list

Re: Reading the access attributes of directories in Windows

[Thomas Jollans]

On Friday 20 August 2010, it occurred to Nobody to exclaim:
> Unix lacks the "Append Data" permission for files, and the "Create Files",
> "Create Folders" and "Delete Subfolders and Files" correspond to having
> write permission on a directory.

How does append differ from write? If you have appending permissions, but not 
writing ones, is it impossible to seek? Or is there a more complex "block" 
that bites you when you seek to before the old end of file and try writing 
there?

Thank you for the insights, "Nobody". Makes me wonder whether SELinux makes 
changes in this area, and if so, how far-reaching they are.


> On Unix, you can read permissions (and attributes if the filesystem has
> them) for any file which you can "reach" (i.e. have "x" permission on all
> ancestor directories). You can only change permissions (and some
> attributes) if you own the file, and only root can change ownership (and
> change some attributes).
> 
> 2. Permissions can be inherited from the "parent object" (which isn't
> necessarily the parent folder). If you change a permission on the parent
> object, it automatically affects any file or folder which inherits the
> permission.
> 
> 3. The owner can be either a user or a group.

What about both?
 
> 4. On Windows, a file cannot be "given away" either by its owner or an
> administrator. You can grant the "Take Ownership" permission, but
> the recipient still has to explicitly change the ownership.

Really? So the operating system actually places restrictions on what the 
administrator can do? 

Or is there a fine distinction here between administrator-accounts in general 
and the NT "Administrator" account that at least some versions of Windows (xp 
home edition springs to mind) appear to try to hide as best they can ? Well, 
this is probably just my UNIX conditioning, expecting a single all-powerful 
super-user, shining through here -- but it does seam strange to have a super-
user that is not omnipotent.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[Peter Otten]

m_ahlenius wrote:

> I am using Python 2.6.5.
> 
> Unfortunately I don't have other versions installed so its hard to
> test with a different version.
> 
> As for the log compression, its a bit hard to test.  Right now I may
> process 100+ of these logs per night, and will get maybe 5 which are
> reported as corrupt (typically a bad CRC) and 2 which it reported as a
> bad tar archive.  This morning I checked each of the 7 reported
> problem files by manually opening them with "tar -xzvof" and they were
> all indeed corrupt. Sign.

So many corrupted files? I'd say you have to address the problem with your 
infrastructure first.
 
> Unfortunately due to the nature of our business, I can't post the data
> files online, I hope you can understand.  But I really appreciate your
> suggestions.
> 
> The thing that gets me is that it seems to work just fine for most
> files, but then not others.  Labeling normal files as corrupt hurts us
> as we then skip getting any log data from those files.
> 
> appreciate all your help.

I've written an autocorruption script, 

import sys
import subprocess
import tarfile

def process(source, dest, data):
for pos in range(len(data)):
for bit in range(8):
new_data = data[:pos] + chr(ord(data[pos]) ^ (1

Re: Python "why" questions

[Russ P.]

On Aug 20, 1:23 am, Martin Braun  wrote:

> I find this thread extremely interesting, but what surprised me that
> everyone seems to agree that mathematics is 1-based, but we Pythoneers
> should stick to zero-based. I disagree. To make sure I'm not going
> crazy, I took the top five books lying on my desk, which were the DSP
> book by Oppenheim/Schafer, two books by Stephen M. Kay (Spectral
> Estimation and Estimation Theory) and the Channel Coding book by Lin &
> Costello. This is isn't pure mathematics (as in proving the Goldbach
> conjecture), but nevertheless, this is serious mathematics and,
> surprise, they most exclusively use zero-based notation.
> You probably don't have those books in grabbing distance, so here's some
> examples for zero-based stuff:

That's interesting, but I think zero-based indexing is rare in the
literature of mathematics, applied math, science and engineering. All
the literature I've ever seen that uses vectors and matrices is one-
based, and that includes text books and technical papers.

It all boils down to personal preference, but I just find it strange
that we would not try to make programming as consistent as possible
with notational conventions in the literature. If I try to implement
some algorithm I find in a technical book or paper, why should I have
to mentally offset every index by one? That's very error prone, and I
have more important things to think about. Then again, I don't do that
very often, so maybe it's not a big deal.

The zero-based indexing just seemed wrong to me when I first saw it.
I'm used to it by now, but it still doesn't seem quite right to me.
It's almost right -- but it's off by one. I still have a habit of
taking the "1" element when I really want the "0" element.

Most programmers probably never use vectors and matrices, so they
don't care about the inconsistency with standard mathematical
notation.

And yes, I understand that zero-based indexing can be slightly more
efficient. That's why I think it's appropriate for low-level languages
such as C. However, I think one-based indexing is more appropriate for
high-level languages.
-- 
http://mail.python.org/mailman/listinfo/python-list

scope of variable

[M B]

Hi, 
I try to learn python.
I don't understand this:

(running in idle)

>>> dept=0
>>> def mud():
print dept


>>> mud()
0
>>> def mud():
dept+=1
print dept


>>> mud()
Traceback (most recent call last):
  File "", line 1, in 
mud()
  File "", line 2, in mud
dept+=1
UnboundLocalError: local variable 'dept' referenced before assignment
>>> 

Regards MB

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

Re: Python "why" questions

[geremy condra]

On Fri, Aug 20, 2010 at 11:01 AM, Russ P.  wrote:
> On Aug 20, 1:23 am, Martin Braun  wrote:
>
>> I find this thread extremely interesting, but what surprised me that
>> everyone seems to agree that mathematics is 1-based, but we Pythoneers
>> should stick to zero-based. I disagree. To make sure I'm not going
>> crazy, I took the top five books lying on my desk, which were the DSP
>> book by Oppenheim/Schafer, two books by Stephen M. Kay (Spectral
>> Estimation and Estimation Theory) and the Channel Coding book by Lin &
>> Costello. This is isn't pure mathematics (as in proving the Goldbach
>> conjecture), but nevertheless, this is serious mathematics and,
>> surprise, they most exclusively use zero-based notation.
>> You probably don't have those books in grabbing distance, so here's some
>> examples for zero-based stuff:
>
> That's interesting, but I think zero-based indexing is rare in the
> literature of mathematics, applied math, science and engineering. All
> the literature I've ever seen that uses vectors and matrices is one-
> based, and that includes text books and technical papers.

Not sure what you read, but for me (mostly number theory, numerical
analysis, and abstract algebra) zero-based indexing is quite common.

> It all boils down to personal preference, but I just find it strange
> that we would not try to make programming as consistent as possible
> with notational conventions in the literature. If I try to implement
> some algorithm I find in a technical book or paper, why should I have
> to mentally offset every index by one? That's very error prone, and I
> have more important things to think about. Then again, I don't do that
> very often, so maybe it's not a big deal.

Ever read code by a mathematician? It's usually (obviously not always)
a nightmare. I'm glad we break with convention, particularly when that
convention is things like one-letter variables and 'reuse' of
notation.

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

Re: scope of variable

[Chris Rebert]

On Fri, Aug 20, 2010 at 11:09 AM, M B  wrote:
> Hi,
> I try to learn python.
> I don't understand this:

 dept=0

 def mud():
>        dept+=1
>        print dept
>
 mud()
> Traceback (most recent call last):
>  File "", line 1, in 
>    mud()
>  File "", line 2, in mud
>    dept+=1
> UnboundLocalError: local variable 'dept' referenced before assignment

http://www.mail-archive.com/python-list@python.org/msg75263.html

Cheers,
Chris
--
Google is your friend
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of variable

[Rony]

On Aug 20, 8:25 pm, Chris Rebert  wrote:
> On Fri, Aug 20, 2010 at 11:09 AM, M B  wrote:
> > Hi,
> > I try to learn python.
> > I don't understand this:
> 
>  dept=0
> 
>  def mud():
> >        dept+=1
> >        print dept
>
>  mud()
> > Traceback (most recent call last):
> >  File "", line 1, in 
> >    mud()
> >  File "", line 2, in mud
> >    dept+=1
> > UnboundLocalError: local variable 'dept' referenced before assignment

Just put a global dept at the start of your function and it will work

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

Re: A question to experienced Pythoneers

[Martin Gregorie]

On Fri, 20 Aug 2010 17:16:14 +0200, Bruno Desthuilliers wrote:

> Rony a écrit :
>> It looks like I forgot to specify that the product is a totaly new
>> product build from scratch, not an upgrade from an existing product.
> 
> 
> Still the advice to first find out what went wrong with the previous
> project is a very sensible one. Technical problems do exist, but from
> experience they rarely are the main source of failure.
>
And be sure to look into the estimation and costing methods the company 
is using. IOW are you sure whether design/build/test phases are 
overrunning a sensible estimate or if the initial costing and estimation 
is underestimating the project size?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: urllib "quote" problem

[John Nagle]

On 8/20/2010 8:41 AM, Aahz wrote:

In article<4c5eef7f$0$1609$742ec...@news.sonic.net>,
John Nagle  wrote:


 This looks like code that will do the wrong thing in
Python 2.6 for characters in the range 128-255.  Those are
illegal in type "str", but this code is constructing such
values with "chr".


WDYM "illegal"?


  Type "str" in Python 2.6 is ASCII, 0..127.

John Nagle

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

Re: Looking for an appropriate encoding standard that supports all languages

[John Nagle]

On 8/20/2010 9:07 AM, Rami Chowdhury wrote:

On Fri, Aug 20, 2010 at 21:02, ata.jaf  wrote:

On Aug 19, 11:48 am, Steven D'Aprano  wrote:

On Thu, 19 Aug 2010 01:29:51 -0700, ata.jaf wrote:

On Aug 17, 11:55 pm, Thomas Jollans  wrote:

Yes I have a source code encoding line.
Here it is:

# -*- coding: utf_16 -*-


   Try "utf_8".


I am using WxPython.

And the error that I get about using utf-16 is:\

Traceback (most recent call last):
  File "", line 1, in
  File "z.py", line 2
SyntaxError: UTF-16 stream does not start with BOM


Which encoding are you saving your script in? Very few of the text
editors I've used save to UTF-16 by default.


   Most editors that will do Unicode save files as "utf-8".
Try that.

John Nagle

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

Re: Looking for an appropriate encoding standard that supports all languages

[Thomas Jollans]

On Thursday 19 August 2010, it occurred to ata.jaf to exclaim:
> On Aug 17, 11:55 pm, Thomas Jollans  wrote:
> > On Tuesday 17 August 2010, it occurred to ata.jaf to exclaim:
> > > I am developing a little program in Mac with wxPython.
> > > But I have problems with the characters that are not in ASCII. Like
> > > some special characters in French or Turkish.
> > > So I am looking for a way to solve this. Like an encoding standard
> > > that supports all languages. Or some other way.
> > 
> > Anything that supports all of Unicode will do. Like UTF-8. If your text
> > is mostly Latin, then just go for UTF-8, if you use other alphabets
> > extensively, you might want to consider UTF-16, which might the use a
> > little less space.
> 
> OK, I used UTF-8.
> I write a line of strings in the source code and I want my program to
> show that as an output on GUI. And this line of strings includes a
> character like "ü". But I see that in GUI this character is replaced
> with another strange characters. I mean it doesn't work.
> And when I try to use UTF-16, I get an syntax error that declares
> "UTF-16 stream does not start with BOM".

I get the feeling you're not actually using the encoding you say you're using, 
or not telling every program involved what you're doing.

1. Save the file in the correct encoding. Either tell your text editor to use 
a specific encoding (UTF-8 would be a good choice), or find out what encoding 
your text editor is using and use that encoding during the rest of the 
process.

2. Tell Python which encoding you're using. The coding: line will do the 
trick, *provided* you don't lie, and the encoding your specify in the file is 
actually the encoding you're using to store the file on disk.

3. Instruct your GUI library to do the right thing. If you use unicode strings 
(either by using Python 3 or by using the u"Käse" syntax in Python 2), that 
should be enough, otherwise, if you're using byte strings, which you shouldn't 
be doing in this case, you might have to tell the library what you're doing, 
or use the customary encoding. (For GTK+, this is UTF-8. For other libraries, 
it might be Latin-1, or system-dependent)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: urllib "quote" problem

[Robert Kern]

On 8/20/10 1:50 PM, John Nagle wrote:

On 8/20/2010 8:41 AM, Aahz wrote:

In article<4c5eef7f$0$1609$742ec...@news.sonic.net>,
John Nagle wrote:


This looks like code that will do the wrong thing in
Python 2.6 for characters in the range 128-255. Those are
illegal in type "str", but this code is constructing such
values with "chr".


WDYM "illegal"?


Type "str" in Python 2.6 is ASCII, 0..127.


In Python 2.6, type "str" is comprised of bytes 0..255, not ASCII characters.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: [ANN]VTD-XML 2.9

[John Krukoff]

On Thu, 2010-08-19 at 17:40 -0700, dontcare wrote:
> VTD-XML 2.9, the next generation XML Processing API for SOA and Cloud
> computing, has been released. Please visit  
> https://sourceforge.net/projects/vtd-xml/files/
> to download the latest version.
> 
> * Strict Conformance
>   # VTD-XML now fully conforms to XML namespace 1.0 spec
> * Performance Improvement
>   # Significantly improved parsing performance for small XML files
> * Expand Core VTD-XML API
>   # Adds getPrefixString(), and toNormalizedString2()
> * Cutting/Splitting
>   # Adds getSiblingElementFragment()
> * A number of bug fixes and code enhancement including:
>   # Fixes a bug for reading very large XML documents on some
> platforms
>   # Fixes a bug in parsing processing instruction
>   # Fixes a bug in outputAndReparse()

So, correct me if I'm wrong, but it doesn't look like this project even
has a python version. So, why is it on the python-announce list?

-- 
John Krukoff
Land Title Guarantee Company
jkruk...@ltgc.com

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

Re: urllib "quote" problem

[MRAB]

John Nagle wrote:

On 8/20/2010 8:41 AM, Aahz wrote:

In article<4c5eef7f$0$1609$742ec...@news.sonic.net>,
John Nagle  wrote:


 This looks like code that will do the wrong thing in
Python 2.6 for characters in the range 128-255.  Those are
illegal in type "str", but this code is constructing such
values with "chr".


WDYM "illegal"?


  Type "str" in Python 2.6 is ASCII, 0..127.


Actually 'str' in Python 2.6 is bytestring, or ASCII + other characters,
by which I mean that the other characters aren't affected by .lower,
etc.
--
http://mail.python.org/mailman/listinfo/python-list

Re: scope of variable

[Burton Samograd]

M B  writes:

> Hi, 
 dept=0
 def mud():
>   print dept
>
>   
 mud()
> 0
 def mud():
>   dept+=1
>   print dept

You should add a global statement or else python thinks a variable used
is a local:

>>> def mud():
global dept
dept+=1
print dept

--
Burton Samograd

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

How to Customize the New 2.7 ArgumentParser Library Class (module argparse)?

[Tom Browder]

I have converted from OptionParser to ArgumentParser (new in version
2.7) to great advantage, and I think it's a great improvement!  But
now I want to customize the help formatting just a bit.

The documentation is sketchy here, but I started by subclassing
ArgumentParser and attempted to redefine format_usage, but after
looking at the detailed instructions with pydoc I see "the API of the
formatter objects is still considered an implementation detail."

I take that to mean I should abandon such efforts at the moment.

So, using the defined class as is, and following instructions in the
online docs, I have been able to get my output to look like this:

==>
$ test_argparser.py -h
usage: test_argparser.py [options]

A program to manipulate user programs.

optional arguments:
  -h, --help  Show this help message and exit.
  -v, --version  Show program's version number and exit.
  -s, --show Show a list of user post-processing programs.

Version 2010-08-20.01
<==

To beautify things I would like to change two strings which are
auto-generated by the standard parser:

1.  change "usage:"

to  "Usage:"   # capitalize 'usage'

2.  change "optional arguments:"

to "Optional arguments:"  # capitalize 'Optional'

Does anyone know how to do it without modifying source code?

Thanks,

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python "why" questions

[Russ P.]

On Aug 20, 11:19 am, geremy condra  wrote:

> Not sure what you read, but for me (mostly number theory, numerical
> analysis, and abstract algebra) zero-based indexing is quite common.

My background is in aerospace control engineering. I am certainly not
familiar with the literature in pure mathematics, but I assume that
the math textbooks I used on college used standard mathematical
notation.

If one-based indexing is becoming more common in the literature, I'll
bet that is only because it is so widely used in computer programming
-- not because the writers decided independently that it is a better
notation. But that's just a guess on my part.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to convert bytearray into integer?

[Thomas Jollans]

On Tuesday 17 August 2010, it occurred to Jacky to exclaim:
> On Aug 17, 3:38 am, Thomas Jollans  wrote:
> > On Monday 16 August 2010, it occurred to Jacky to exclaim:
> > > it's hard to image why socket object provides the interface:
> > > socket.recv_from(buf[, num_bytes[, flags]]) but forget the more
> > > generic one: socket.recv_from(buf[, offset[, num_bytes[, flags]]])
> > 
> > Well, that's what pointer arithmetic (in C) or slices (in Python) are
> > for! There's an argument to be made for sticking close to the
> > traditional (originally C) interface here - it's familiar.
> 
> Hi Thomas, - I'm not quite follow you.  It will be great if you could
> show me some code no this part...

When I originally wrote that, I didn't check the Python docs, I just had a 
quick look at the manual page.

This is the signature of the BSD-socket recv function: (recv(2))

   ssize_t recv(int sockfd, void *buf, size_t len, int flags);

so, to receive data into a buffer, you pass it the buffer pointer.

len = recv(sock, buf, full_len, 0);

To receive more data into another buffer, you pass it a pointer further on:

len = recv(sock, buf+len, full_len-len, 0);
/* or, this might be clearer, but it's 100% the same: */
len = recv(sock, & buf[len], full_len-len, 0);

Now, in Python. I assume you were referring to socket.recv_into:

socket.recv_into(buffer[, nbytes[, flags]])

It's hard to imagine why this method exists at all. I think the recv method is 
perfectly adequate:

buf = bytearray()
buf[:] = sock.recv(full_len)
# then:
lngth = len(buf)
buf[lngth:] = sock.recv(full_len - lngth)

But still, nothing's stopping us from using recv_into:

# create a buffer large enough. Oh this is so C...
buf = bytearray([0]) * full_len
lngth = sock.recv_into(buf, length_of_first_bit)
 # okay, now let's fill the rest !
sock.recv_into(memoryview(buf)[lngth:])

In C, you can point your pointers where ever you want. In Python, you can 
point your memoryview at buffers in any way you like, but there tend to be 
better ways of doing things.

Cheers,

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

Re: scope of variable

[M B]

fre 2010-08-20 klockan 13:19 -0600 skrev Burton Samograd:
> M B  writes:
> 
> > Hi, 
>  dept=0
>  def mud():
> > print dept
> >
> > 
>  mud()
> > 0
>  def mud():
> > dept+=1
> > print dept
> 
> You should add a global statement or else python thinks a variable used
> is a local:
> 
> >>> def mud():
> global dept
>   dept+=1
>   print dept
> 
> --
> Burton Samograd
> 
Ok.  Thanks for the answers. :)  I was a bit puzzled of
the fact that I could read but not assign to a global variable.

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

Re: Python "why" questions

[geremy condra]

On Fri, Aug 20, 2010 at 12:31 PM, Russ P.  wrote:
> On Aug 20, 11:19 am, geremy condra  wrote:
>
>> Not sure what you read, but for me (mostly number theory, numerical
>> analysis, and abstract algebra) zero-based indexing is quite common.
>
> My background is in aerospace control engineering. I am certainly not
> familiar with the literature in pure mathematics, but I assume that
> the math textbooks I used on college used standard mathematical
> notation.
>
> If one-based indexing is becoming more common in the literature, I'll
> bet that is only because it is so widely used in computer programming
> -- not because the writers decided independently that it is a better
> notation. But that's just a guess on my part.

I can't speak for the motivation for selecting that notation, but I'm
not sure it matters anyway- if the rationale for a switch is to become
consistent with mathematical notation and the 0-based indexing is
becoming a common notation in that field then we achieve consistency
by standing still.

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

Re: Iterative vs. Recursive coding

[John Bokma]

John Nagle  writes:

> Python does not do tail recursion, so using recursion
> where iteration could do the job is generally a bad idea.  Scheme, on
> the other hand, always does tail recursion where possible.

I think you mean tail recursion optimization / elimination.
Python does tail recursion:

>>> def x(n):
... if n == 10: return
... print n
... x(n + 1)
... 
>>> x(1)
1
2
3
4
5
6
7
8
9


-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl & Python Development: http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to Customize the New 2.7 ArgumentParser Library Class (module argparse)?

[Peter Otten]

Tom Browder wrote:

> I have converted from OptionParser to ArgumentParser (new in version
> 2.7) to great advantage, and I think it's a great improvement!  But
> now I want to customize the help formatting just a bit.
> 
> The documentation is sketchy here, but I started by subclassing
> ArgumentParser and attempted to redefine format_usage, but after
> looking at the detailed instructions with pydoc I see "the API of the
> formatter objects is still considered an implementation detail."
> 
> I take that to mean I should abandon such efforts at the moment.
> 
> So, using the defined class as is, and following instructions in the
> online docs, I have been able to get my output to look like this:
> 
> ==>
> $ test_argparser.py -h
> usage: test_argparser.py [options]
> 
> A program to manipulate user programs.
> 
> optional arguments:
>   -h, --help  Show this help message and exit.
>   -v, --version  Show program's version number and exit.
>   -s, --show Show a list of user post-processing programs.
> 
> Version 2010-08-20.01
> <==
> 
> To beautify things I would like to change two strings which are
> auto-generated by the standard parser:
> 
> 1.  change "usage:"
> 
> to  "Usage:"   # capitalize 'usage'
> 
> 2.  change "optional arguments:"
> 
> to "Optional arguments:"  # capitalize 'Optional'
> 
> Does anyone know how to do it without modifying source code?

You can use internationalization via

http://docs.python.org/library/gettext.html

or take a shortcut:

$ cat tmp.py
lookup = {
"usage: ": "Usage: ",
"optional arguments": "Optional arguments"}

def gettext(s):
return lookup.get(s, s)

import argparse
argparse._ = gettext

if __name__ == "__main__":
p = argparse.ArgumentParser()
p.parse_args()

$ python tmp.py -h
Usage: tmp.py [-h]

Optional arguments:
  -h, --help  show this help message and exit

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

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Hugh Aguilar]

On Aug 18, 6:23 pm, Standish P  wrote:
> On Aug 17, 6:38 pm, John Passaniti  wrote:
>
> > You asked if Forth "borrowed" lists from Lisp.  It did not.  In Lisp,
> > lists are constructed with pair of pointers called a "cons cell".
> > That is the most primitive component that makes up a list.  Forth has
> > no such thing; in Forth, the dictionary (which is traditionally, but
> > not necessarily a list) is a data structure that links to the previous
> > word with a pointer.  
>
> Would you show me a picture, ascii art or whatever for Forth ? I know
> what lisp lists look like so I dont need that for comparison. Forth
> must have a convention and a standard or preferred practice for its
> dicts. However, let me tell you that in postscript the dictionaries
> can be nested inside other dictionaries and any such hiearchical
> structure is a nested associative list, which is what linked list,
> nested dictionaries, nested tables are.

You can see an example of lists in my novice package (in the list.4th
file):
http://www.forth.org/novice.html
Also in there is symtab, which is a data structure intended to be used
for symbol tables (dictionaries). Almost nobody uses linked lists for
the dictionary anymore (the FIG compilers of the 1970s did, but they
are obsolete).

I must say, I've read through this entire thread and I didn't
understand *anything* that *anybody* was saying (especially the OP). I
really recommend that people spend a lot more time writing code, and a
lot less time with all of this pseudo-intellectual nonsense. This
whole thread (and most of what I see on C.L.F. these days) reminds me
of the "dialectic method" of the early Middle Ages --- a lot of talk
and no substance.

Write some programs! Are we not programmers?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reading the access attributes of directories in Windows

[vsoler]

On Aug 20, 7:42 pm, Tim Golden  wrote:
> On 20/08/2010 5:10 PM, vsoler wrote:
>
>
>
> > On Aug 20, 5:10 pm, Tim Golden  wrote:
> >> To decode the permission bit-strings to vaguely meaningful
> >> names:
>
> >> 
> >> import os, sys
> >> from winsys import fs
>
> >> dacl = fs.file (sys.executable).security ().dacl
> >> for permission in dacl:
> >>     print (d.trustee, " (Inherited )" if d.inherited else "")
> >>     for name in fs.FILE_ACCESS.names_from_value (d.access):
> >>       print ("  ", name)
>
> >> 
>
> >> TJG
>
> > it seems as though the definition of "d" is missing in your last piece
> > of code
>
> Whoops, changed tack mid-thingy. Try:
>
> dacl = ...
> for d in dacl:
>    # .. as before

Tim,

I'am testing your library. I am mainly interested in knowing the
access attributes of directories in the local(C:\) or shared unit(W:\)
of my system.

Using your script with 'c:\\' I get an error message saying... 'file
exists but it is a directory' and I cannot go any further.

Of course, the problem is that I am using "fs.file" when I should be
using something different.

Reading the doc I have found that I should be using os.walk(...),
which works, but then I cannot use fs.file

Could you please give me a hint as to what metghod I should be using?

Thank you

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

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Hugh Aguilar]

On Aug 18, 6:13 pm, Standish P  wrote:
> > Mostly it had a "snowball's chance" because it was never picked up by
> > the CS gurus who, AFAIK, never really took a serious look at it.
>
> Its quite possible that the criticism is unfair, but dont you think
> that in part some responsibility must be borne by your organization in
> not doing a good job of education ?
> ...
> She is quite humble. Take a look at this page,
>
> http://www.forth.com/resources/evolution/index.html

That is actually pretty humorous; she managed to describe herself as a
"leading expert" twice in a single short paragraph. LOL

See! I do have a sense of humor!
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4c4dba9135bcf03e/8086ee13095bf78c
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Iterative vs. Recursive coding

[Ben Finney]

Steven D'Aprano  writes:

> On Thu, 19 Aug 2010 22:00:16 +, Martin Gregorie wrote:
>
> > Recursion can be quite a trick to get your mind round at first
>
> Really? Do people actually find the *concept* of recursion to be
> tricky?

Evidently so. It's folk wisdom that some adults find recursion an easy
concept, and those people will find programming significantly easier;
and the majority of people have a great deal of difficulty with
recursion and so find programming correspondingly difficult.

There is evidence that the phenomenon is at least significant and
measurable http://portal.acm.org/citation.cfm?id=53033>.

There is all manner of speculation as to what might cause this divide in
capability, but precious little scientific research has been done on the
differences between such people AFAICT.

-- 
 \   “Two possibilities exist: Either we are alone in the Universe |
  `\   or we are not. Both are equally terrifying.” —Arthur C. Clarke, |
_o__) 1999 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

make install DESTDIR

[aj]

I am trying to install python with make install DESTDIR=/home/blah

./python -E ./setup.py install \
--prefix=/ \
--install-scripts=//bin \
--install-platlib=//lib/python2.6/lib-dynload \
--root=//home/blah
running install
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers

Failed to find the necessary bits to build these modules:
_tkinter   bsddb185   dl
imageopsunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for
the module's name.

running build_scripts
running install_lib
creating /lib/python2.6
error: could not create '/lib/python2.6': Permission denied
make: *** [sharedinstall] Error 1
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Iterative vs. Recursive coding

[Baba]

Hi Martin

Thanks for your post. This basic but fundamental computation is a
great example when trying to understand the concept of recursion for
the first time.

Also thanks to John for the stackoverflow link where i found a very
good summarised definition completing some of the posts left here.

For future readers of this post who want to learn to programm (just
like myself) let me re-state the basics i have learned now:

- a procedure is said to be recursive when it contains a statement
that calls itself
- there must be a condition where the recursion has to stop otherwise
the routine will continue to call itself infinitely.
  This is called the Base Case
- every time the procedure calls itself the memory gradually fills up
with the copies until the whole thing winds down again
  as the "return" statements start being executed.
- the above point means that a recursive approach is expensive on
resources so in the practical world it should be avoided.
  (Thanks John for giving me a real life example where recursion is
recommended)

For the purposes of learning programming i think it's a must to
understand Recursion so thanks all for your help!

Ok so now i hope you all agree that my code is also correct :)

def r_countSubStringMatch(target,key):
counter=0
if len(key)http://mail.python.org/mailman/listinfo/python-list

Re: make install DESTDIR

[Thomas Jollans]

On Saturday 21 August 2010, it occurred to aj to exclaim:
> I am trying to install python with make install DESTDIR=/home/blah
> 

> --prefix=/ 

...

> creating /lib/python2.6
> error: could not create '/lib/python2.6': Permission denied
> make: *** [sharedinstall] Error 1

Obviously, the flags you specified didn't have the effect you intended. 

  --prefix=$HOME

should do the trick.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Iterative vs. Recursive coding

[Baba]

On Aug 19, 11:00 pm, Martin Gregorie 
wrote:

> By way of a hint, here are two versions of the classic example of
> recursion: calculating factorials. Recursion can be quite a trick to get
> your mind round at first, so compare the two and follow through their
> operation step by step...

Hi Martin

Thanks for your post. This basic but fundamental computation
(calculating factorials) is a great example when trying to
understand the concept of recursion for the first time.

Also thanks to John for the stackoverflow link where i found a very
good summarised definition completing some of the posts left here.

For future readers of this post who want to learn to programm (just
like myself) let me re-state the basics i have learned now:

- a procedure is said to be recursive when it contains a statement
that calls itself
- there must be a condition where the recursion has to stop otherwise
the routine will continue to call itself infinitely.
  This is called the Base Case
- every time the procedure calls itself the memory gradually fills up
with the copies until the whole thing winds down again
  as the "return" statements start being executed.
- the above point means that a recursive approach is expensive on
resources so in the practical world it should be avoided.
  (Thanks John for giving me a real life example where recursion is
recommended)

For the purposes of learning programming i think it's a must to
understand Recursion so thanks all for your help!

Ok so now i hope you all agree that my code is also correct :)

def r_countSubStringMatch(target,key):
counter=0
if len(key)http://mail.python.org/mailman/listinfo/python-list

Re: Iterative vs. Recursive coding

[Thomas Jollans]

On Saturday 21 August 2010, it occurred to Baba to exclaim:
> - every time the procedure calls itself the memory gradually fills up
> with the copies until the whole thing winds down again
>   as the "return" statements start being executed.
> - the above point means that a recursive approach is expensive on
> resources so in the practical world it should be avoided.
>   (Thanks John for giving me a real life example where recursion is
> recommended)

This is only partly true. In most programming languages "typical" today, this 
is true: each recursion is a normal function call which allocates space on the 
stack. Thus, the maximum recursion depth is severely limited.

However, in most functional programming languages, recursion is recognized as 
a highly expressive, powerful, and idiomatic tool that can often be optimized. 
Languages like haskell or scheme compile tail-end recursive functions in a 
manner that is just as efficient as a loop would have been. In general, if you 
could rewrite a recursive scheme function to use a loop, then a decent scheme 
compiler will be able to "do it for you" behind the scenes.

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

Re: Python "why" questions

[Gregory Ewing]

Lawrence D'Oliveiro wrote:

That is not some kind of ordinal numbering of the terms, that is the power 
of the variable involved.


It's both. Convention is to make the power and the index
of the coefficent the same, because it would be pointlessly
confusing to do anything else.

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

Re: Python "why" questions

[Gregory Ewing]

Martin Gregorie wrote:

On Mon, 16 Aug 2010 12:33:51 +1200, Gregory Ewing wrote:



Ian Kelly wrote:


On Fri, Aug 13, 2010 at 11:53 AM, Martin Gregorie
 wrote:



 real sample[-500:750];



Ugh, no.  The ability to change the minimum index is evil.


Not always; it can have its uses, particularly when you're using the
array as a mapping rather than a collection.



Say you have intensity data captured from an X-ray goniometer from 160 
degrees to 30 degrees at 0.01 degree resolution. Which is most evil of 
the following?


1) real intensity[16000:3000]
   for i from lwb intensity to upb intensity
  plot(i/100, intensity[i]);

2) double angle[13000];
   double intensity[13000];
   for (int i = 0; i < 13000; i++)
plot(angle[i], intensity[i]);

3) struct 
   { 
  double angle;
  double intensity 
   } measurement;

   measurement m[13000];
   for (int i = 0; i < 13000; i++)
plot(m[i].angle, m[i].intensity);

4) double intensity[13000];
   for (int i = 0; i < 13000; i++)
  plot((16000 - i)/100, intensity[i])
 
To my mind (1) is much clearer to read and far less error-prone to write, 
while zero-based indexing forces you to use code like (2), (3) or (4), 
all of which obscure rather than clarify what the program is doing.


This might be true if the only thing you ever do with your
indices is use them to iterate over the array. However, if
you need to do any arithmetic with them, you may find yourself
thinking again.

Also, in Python you wouldn't write iteration loops that way
in the first place. You would write things such as

  for x, y in zip(angle, intensity):
plot(x, y)

which avoids dealing with indexes altogether. The only time
you really need to use indexes in Python is when you want to
do arithmetic with them, or take slices, both of which turn
out to be less confusing most of the time with 0-based indexing.

--
Greg


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

Re: Python "why" questions

[Gregory Ewing]

Robert Kern wrote:

On 8/16/10 9:29 PM, Roy Smith wrote:


In article,
  Lawrence D'Oliveiro  wrote:


In message, Roy Smith wrote:


5) real intensity[160.0 : 30.0 : 0.01]


How many elements in that array?


c) neither of the above.  More specifically, 13,001 (if I counted
correctly).


13000, actually. Floating point is a bitch.


Or 12999.999 if you're unlucky. Floating point is a *real* bitch!

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

Re: Python "why" questions

[Gregory Ewing]

J.B. Brown wrote:


Then users of my class (mainly my research lab coworkers) could
specify whichever behavior they wanted.

In terms of providing readable code and removing beginning programmer
confusion,


But having some arrays indexed from 0 and others from 1 can
be a recipe for confusion in its own right.

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

Re: Iterative vs. Recursive coding

[Martin Gregorie]

On Fri, 20 Aug 2010 16:22:44 -0700, Baba wrote:

> For the purposes of learning programming i think it's a must to
> understand Recursion so thanks all for your help!
>
That depends on the language and/or hardware. COBOL wouldn't understand 
recursion if hit on the head with a recursion brick and early computer 
hardware (those without a stack) made it VERY hard work. If you don't 
follow this, look at the CODASYL language specification for COBOL or the 
hardware design of ICL 1900 or IBM System/360 mainframes (which are still 
the heart of the financial world) and work out how to implement a 
recursive function for any of them. Its not easy but it can be done.
  
> Ok so now i hope you all agree that my code is also correct :)
> 
Yes: it runs and does what I'd expect. A good result.

A basic skill for a programmer is to understand the specification for a 
piece of code and write test cases. This is a set of inputs (both 
expected/sensible and totally out of order) and the expected outputs from 
each set of inputs. Then you write the code and run it against the test 
cases to show that it does what the specification requires. 

Never bullshit yourself or anybody else about this conformance to spec: 
either you screwed up or, hopefully less often, the designer wrote an 
ambiguous or plain wrong requirement. Either way, the problem must be 
resolved and the code be made to do what is wanted. 

while (results don't match the spec):
Rince, wash, repeat.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: make install DESTDIR

[aj]

On Aug 20, 4:39 pm, Thomas Jollans  wrote:
> On Saturday 21 August 2010, it occurred to aj to exclaim:
>
> > I am trying to install python with make install DESTDIR=/home/blah
>
> >                 --prefix=/
>
> ...
>
> > creating /lib/python2.6
> > error: could not create '/lib/python2.6': Permission denied
> > make: *** [sharedinstall] Error 1
>
> Obviously, the flags you specified didn't have the effect you intended.
>
>   --prefix=$HOME
>
> should do the trick.

The whole point of DESTDIR is that it should be prepended to all
installed paths, but the binaries should not contain any references to
it.DESTDIR is commonly used by packagers, for example, to allow
installation without superuser privileges.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python "why" questions

[Gregory Ewing]

Martin Braun wrote:


Another thing worth mentioning (I guess here is a good a place as any
other) is the fact that programming and mathematics are still pretty
different things, despite how much we programmers would like to think
ourselves as some kind of mathematician.  


Although when it comes to indexing, mathematics and programming
have remarkably similar issues. I've seen mathematics texts that
made a poor choice of index base and ended up with formulas
confusingly littered with plus and minus ones, or where I've
had to scratch my head a few times and look back to find out
whether a particular index was meant to start from 0 or 1.

Also it doesn't help that the sigma notation lends itself more
to closed than half-open intervals, which can lead to a
Hobson's choice between i-1 in the formulas and n-1 in the
summation range.

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

Re: Python "why" questions

[Gregory Ewing]

Russ P. wrote:

It all boils down to personal preference, but I just find it strange
that we would not try to make programming as consistent as possible
with notational conventions in the literature.


It doesn't matter how much mathematical convention you quote,
your assertion that 1-based indexing is better won't convince
me, because it flies in the face of my own personal experience.


The zero-based indexing just seemed wrong to me when I first saw it.
I'm used to it by now, but it still doesn't seem quite right to me.
It's almost right -- but it's off by one. I still have a habit of
taking the "1" element when I really want the "0" element.


That may be because you haven't fully adopted 0-based indexing
into your thinking. You're trying to think in terms of 1-based
indexes and convert to 0-based when you code. If you think in
0-based indexes in the first place, many things become simpler.

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

Re: Pop return from stack?

[Gregory Ewing]

bvdp wrote:


The whole problem I was having is that I was trying to tie a small
application (an helper to the main application) to use a bit of the
existing code as a pseudo-library.


This is precisely the reason that it's a bad idea to
directly terminate the program from somewhere deep inside
the code. It makes it hard to re-use the code in another
context.

It's much better to raise an exception containing an
appropriate error message, catch it at the top level
of the application and print the message and exit there.
Then you can easily re-use any of the code in a context
where it's not appropriate to have it exit out from
under you.


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

Re: Simple Python Sandbox

[Stephen Hansen]

On 8/16/10 7:01 AM, Roland Koebler wrote:
> On Sat, Aug 14, 2010 at 08:01:00PM -0700, Stephen Hansen wrote:
>>> As you can see, black listing isn't the best approach here.
>>
>> But I have a two pronged strategy: the black list is only half of the
>> equation. One, I'm blacklisting all the meta functions out of builtins.
> But blacklists are *never* secure. Sorry, but you should fully understand
> this before even thinking about more detailed security.

And whitelists are never secure, either.

There is no such thing as perfectly secure, no. But that is not a goal
that I've set for this at all. There's more secure, less secure, more
likely to provide a vector for attack, less likely to provide a vector
for attack. Every security precaution does end up having a cost: every
one weakens the resulting environment or makes something someone wants
to do legitimately more hard. Security is always a trade off.

The goal is "secure enough" -- and what 'enough' is is going to vary a
lot depending on different people's needs. If I were in a situation
where I'm executing arbitrary code gathered off of the 'net, that'd be a
very different demand and I'd be a lot more keen on finding a perfect
sand box (and thus would simply not use Python).

That isn't the case here; my relatively untrusted users are uniquely and
specifically identifyable and trackable, their interface to the system
is logged and actions recorded. There's no money involved in this
system, nor possibility that someone could use it to get higher tier
access on the parent machine: if someone gets through the sandbox, it'll
be a nuisance, hurt some people's enjoyment, harm a community, but
really-- it should be able to be fixed pretty rapidly, and then that
person utterly locked out.

I just want a sandbox that is good enough that it'd be really hard for
someone to do that. That's all. Minimize how many times I have to go fix
up something. :)

> Why are you blacklisting the "known-bad" functions instead of whitelising
> the allowed ones??

Because that would annoy some of the other users, who think the status
quo isn't really all that bad and that I'm paranoid :)

Me, I'm going to go farther on my own installation and kill import
entirely, and do a sort of require() which returns a special proxied
version of an imported module only if its on a pre-allowed white-list,
and even then each individual member of said module will have to be
white-listed specifically, too.

But in general, I just want a better sandbox that starts things off
without getting in anyone's way to do totally legitimate sorts of things.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with tarfile module to open *.tar.gz files - unreliable ?

[m_ahlenius]

On Aug 20, 12:55 pm, Peter Otten <__pete...@web.de> wrote:
> m_ahlenius wrote:
> > I am using Python 2.6.5.
>
> > Unfortunately I don't have other versions installed so its hard to
> > test with a different version.
>
> > As for the log compression, its a bit hard to test.  Right now I may
> > process 100+ of these logs per night, and will get maybe 5 which are
> > reported as corrupt (typically a bad CRC) and 2 which it reported as a
> > bad tar archive.  This morning I checked each of the 7 reported
> > problem files by manually opening them with "tar -xzvof" and they were
> > all indeed corrupt. Sign.
>
> So many corrupted files? I'd say you have to address the problem with your
> infrastructure first.
>
> > Unfortunately due to the nature of our business, I can't post the data
> > files online, I hope you can understand.  But I really appreciate your
> > suggestions.
>
> > The thing that gets me is that it seems to work just fine for most
> > files, but then not others.  Labeling normal files as corrupt hurts us
> > as we then skip getting any log data from those files.
>
> > appreciate all your help.
>
> I've written an autocorruption script,
>
> import sys
> import subprocess
> import tarfile
>
> def process(source, dest, data):
>     for pos in range(len(data)):
>         for bit in range(8):
>             new_data = data[:pos] + chr(ord(data[pos]) ^ (1< data[pos+1:]
>             assert len(data) == len(new_data)
>             out = open(dest, "w")
>             out.write(new_data)
>             out.close()
>             try:
>                 t = tarfile.open(dest)
>                 for f in t:
>                     t.extractfile(f)
>             except Exception, e:
>                 if 0 == subprocess.call(["tar", "-xf", dest]):
>                     return pos, bit
>
> if __name__ == "__main__":
>     source, dest = sys.argv[1:]
>     data = open(source).read()
>     print process(source, dest, data)
>
> and I can indeed construct an archive that is rejected by tarfile, but not
> by tar. My working hypothesis is that the python library is a bit stricter
> in what it accepts...
>
> Peter

Thanks - that's cool.

A friend of mine was suggesting that he's seen similar behaviour when
he uses Perl on these types of files when the OS (Unix) has not
finished writing them.  We have an rsync process which sync's our
servers for these files and then come down somewhat randomly.  So its
conceivable I think that this process could be trying to open a file
as its being written.  I know it sounds like a stretch but my guess is
that its a possibility.  I could verify that with the timestamps of
the errors in my log and the mod time on the original file.

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

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[John Passaniti]

On Aug 20, 6:51 pm, Hugh Aguilar  wrote:
> You can see an example of lists in my novice package (in the list.4th
> file):http://www.forth.org/novice.html
> Also in there is symtab, which is a data structure intended to be used
> for symbol tables (dictionaries). Almost nobody uses linked lists for
> the dictionary anymore (the FIG compilers of the 1970s did, but they
> are obsolete).

Thanks for pointing this out, Hugh.  After reading the code in your
novice package and symtab, I am confused:  With code of that caliber
and the obvious stunning intellect behind it, why hasn't everyone
adapted your awesome symtab for symbol tables instead?  Any why hasn't
there been an effort to translate symtab into other languages so users
outside of Forth can also experience the sheer speed and hyper-
efficient use of memory and CPU?  Let me say I find it refreshing that
a great programmer like yourself doesn't bother with stupid fads like
testing algorithms against large data sets and measuring performance
relative to competitive algorithms.  That's all academic nonsense.
The only test and measurement anyone needs are the comments at the top
of symtab where you state your algorithm is better.  You clearly
wouldn't have written that if it wasn't true.

> Write some programs! Are we not programmers?

Amen!  All this academic talk is useless.  Who cares about things like
the big-O notation for program complexity.  Can't people just *look*
at code and see how complex it is?!  And take things like the years of
wasted effort computer scientists have put into taking data structures
(like hashes and various kinds of trees) and extending them along
various problem domains and requirements.  Real programmers don't
waste their time with learning that junk.  What good did any of that
ever do anyone?!

Thanks Hugh for a refreshing stance on what it means to be a
programmer.

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

Re: 79 chars or more?

[Lawrence D'Oliveiro]

In message
, Jean-Michel Pichavant 
wrote:

> Saying that, if one intend to distribute its code, he should stick to 80
> chars per line.

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

OI VEY, I AGREE -was once [Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?]

[Richard Owlett]

John Passaniti wrote:

On Aug 20, 6:51 pm, Hugh Aguilar  wrote:

You can see an example of lists in my novice package (in the list.4th
file):http://www.forth.org/novice.html
Also in there is symtab, which is a data structure intended to be used
for symbol tables (dictionaries). Almost nobody uses linked lists for
the dictionary anymore (the FIG compilers of the 1970s did, but they
are obsolete).


Thanks for pointing this out, Hugh.  After reading the code in your
novice package and symtab, I am confused:  With code of that caliber
and the obvious stunning intellect behind it, why hasn't everyone
adapted your awesome symtab for symbol tables instead?  Any why hasn't
there been an effort to translate symtab into other languages so users
outside of Forth can also experience the sheer speed and hyper-
efficient use of memory and CPU?  Let me say I find it refreshing that
a great programmer like yourself doesn't bother with stupid fads like
testing algorithms against large data sets and measuring performance
relative to competitive algorithms.  That's all academic nonsense.
The only test and measurement anyone needs are the comments at the top
of symtab where you state your algorithm is better.  You clearly
wouldn't have written that if it wasn't true.


Write some programs! Are we not programmers?


Amen!  All this academic talk is useless.  Who cares about things like
the big-O notation for program complexity.  Can't people just *look*
at code and see how complex it is?!  And take things like the years of
wasted effort computer scientists have put into taking data structures
(like hashes and various kinds of trees) and extending them along
various problem domains and requirements.  Real programmers don't
waste their time with learning that junk.  What good did any of that
ever do anyone?!

Thanks Hugh for a refreshing stance on what it means to be a
programmer.



Never thought I I'd agree wholeheartedly with very verbose John.

Hugh, you are complete idiot!

(and other less complementary  ...)
--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Standish P]

On Aug 18, 8:05 pm, Elizabeth D Rather  wrote:
> On 8/18/10 2:23 PM, Standish P wrote:
>
> > On Aug 17, 6:38 pm, John Passaniti  wrote:
>
> >> You asked if Forth "borrowed" lists from Lisp.  It did not.  In Lisp,
> >> lists are constructed with pair of pointers called a "cons cell".
> >> That is the most primitive component that makes up a list.  Forth has
> >> no such thing; in Forth, the dictionary (which is traditionally, but
> >> not necessarily a list) is a data structure that links to the previous
> >> word with a pointer.
>
> > Would you show me a picture, ascii art or whatever for Forth ? I know
> > what lisp lists look like so I dont need that for comparison. Forth
> > must have a convention and a standard or preferred practice for its
> > dicts. However, let me tell you that in postscript the dictionaries
> > can be nested inside other dictionaries and any such hiearchical
> > structure is a nested associative list, which is what linked list,
> > nested dictionaries, nested tables are.
>
> You indicated that you have a copy of Forth Application Techniques.
> Sections 8.1 and 8.2 cover this topic, with some drawings.

Can someone send me a scan copy of sec 8.1 to 8.2 within the exemption
in the copyright law for my personal study and evaluation of the book
only.

I have only looked at the book cover on forth site and its table of
contents on amazon.

why elase would I ask where it is if I had a copy and would go
directly to index assuming it has a good indexing.

Alternative, a link to an open source of explanation would be
requested.

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

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Standish P]

On Aug 20, 3:51 pm, Hugh Aguilar  wrote:
> On Aug 18, 6:23 pm, Standish P  wrote:
>
>
>
>
>
> > On Aug 17, 6:38 pm, John Passaniti  wrote:
>
> > > You asked if Forth "borrowed" lists from Lisp.  It did not.  In Lisp,
> > > lists are constructed with pair of pointers called a "cons cell".
> > > That is the most primitive component that makes up a list.  Forth has
> > > no such thing; in Forth, the dictionary (which is traditionally, but
> > > not necessarily a list) is a data structure that links to the previous
> > > word with a pointer.  
>
> > Would you show me a picture, ascii art or whatever for Forth ? I know
> > what lisp lists look like so I dont need that for comparison. Forth
> > must have a convention and a standard or preferred practice for its
> > dicts. However, let me tell you that in postscript the dictionaries
> > can be nested inside other dictionaries and any such hiearchical
> > structure is a nested associative list, which is what linked list,
> > nested dictionaries, nested tables are.
>
> You can see an example of lists in my novice package (in the list.4th
> file):http://www.forth.org/novice.html
> Also in there is symtab, which is a data structure intended to be used
> for symbol tables (dictionaries). Almost nobody uses linked lists for
> the dictionary anymore (the FIG compilers of the 1970s did, but they
> are obsolete).
>
> I must say, I've read through this entire thread and I didn't
> understand *anything* that *anybody* was saying (especially the OP).

You didnt understand anything because no one explained anything
coherently. Admittedly, I am asking a question that would be thought
provoking to those who claim to be "experts" but these experts are
actually very stingy and mean business people, most certainly worse
than Bill Gates, only it did not occur to them his ideas and at the
right time.


> I really recommend that people spend a lot more time writing code, and a
> lot less time with all of this pseudo-intellectual nonsense.

You have to have a concept to write code.

> This
> whole thread (and most of what I see on C.L.F. these days) reminds me
> of the "dialectic method" of the early Middle Ages --- a lot of talk
> and no substance.
>
> Write some programs! Are we not programmers?- Hide quoted text -
>
> - Show quoted text -

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

Re: Reading the access attributes of directories in Windows

[Tim Golden]

On 20/08/2010 11:54 PM, vsoler wrote:

I'am testing your library. I am mainly interested in knowing the
access attributes of directories in the local(C:\) or shared unit(W:\)
of my system.

Using your script with 'c:\\' I get an error message saying... 'file
exists but it is a directory' and I cannot go any further.

Of course, the problem is that I am using "fs.file" when I should be
using something different.


Either use fs.dir (if you know it's a directory) or fs.entry (if it
could be a file or a directory; the code will dispatch to the right one).

If you only want the directories immediately some directory,
you could do this:


from winsys import fs, security

root = fs.file (sys.executable).path  # or fs.dir ("w:/") etc.
for d in root.dirs (ignore_access_errors=True):
  print (d, "=>", d.security ()) # or whatever



If you want to walk the tree of directories looking at permissions, then:


import os, sys
from winsys import fs

root = fs.file (sys.executable).path
for dirpath, _, _ in root.walk ():
  print (dirpath, "=>", dirpath.security ())





Reading the doc I have found that I should be using os.walk(...),
which works, but then I cannot use fs.file


In fact, even if you did for some reason use os.walk, you can
easily wrap the returned filenames using fs.entry:


import os, sys
from winsys import fs

root = os.path.dirname (sys.executable)
for dirpath, filenames, dirnames in os.walk (root):
  print (dirpath, "=>", fs.entry (dirpath).security ())



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

Re: Iterative vs. Recursive coding

[John Nagle]

On 8/20/2010 1:17 PM, John Bokma wrote:

John Nagle  writes:


 Python does not do tail recursion, so using recursion
where iteration could do the job is generally a bad idea.  Scheme, on
the other hand, always does tail recursion where possible.


I think you mean tail recursion optimization / elimination.
Python does tail recursion:


   Not very well.

def cnt(n) :
if n > 0 :
cnt(n-1)


This will work for up to cnt(998), but at cnt(999), CPython
reports "RuntimeError: maximum recursion depth exceeded."

Yes, you can increase the recursion depth, but that case
shouldn't be compiled to recursion at all.

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

Re: scope of variable

[John Nagle]

On 8/20/2010 12:56 PM, M B wrote:

fre 2010-08-20 klockan 13:19 -0600 skrev Burton Samograd:

M B  writes:


Hi,

dept=0
def mud():

print dept



mud()

0

def mud():

dept+=1
print dept


You should add a global statement or else python thinks a variable used
is a local:


def mud():

 global dept
dept+=1
print dept

--
Burton Samograd


Ok.  Thanks for the answers. :)  I was a bit puzzled of
the fact that I could read but not assign to a global variable.


   If you assign before a read, you create a local variable.

   If you read only, you get a global access.

   If you do a read before an assignment, you get an error message.

John Nagle

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

Re: expression in an if statement

[alex23]

John Nagle  wrote:
> I was talking to the Facebook guys doing the compiler for PHP, and they
> said that it was a huge win for them that PHP doesn't allow dynamically
> replacing a function.

I'm not sure if I call all that effort for a 50% speed increase a win.
PyPy is seeing speed increases of up to 15 times that of CPython 2.6.2
without reducing the flexibility of the language at all.
-- 
http://mail.python.org/mailman/listinfo/python-list