Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On 8/20/10 7:42 PM, Standish P wrote: ... 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. The problem as I see it is that you're asking complex questions in a forum that, at best, supports simple answers. The information you're looking for exists, on the net, free. There are free pdfs of manuals on Forth available with program downloads from FORTH, Inc., MPE, Gforth, and other sources, as well as some inexpensive books. But you have to be willing to make the investment to download and read them, because the answers to your questions are not simple one-liners that you can get from newsgroups, and the folks in newsgroups are not prepared to host computer science seminars -- many of us are working programmers, engineers, and project managers who have limited time to spend here. If you're willing to invest your time enough to investigate some of these sources, and still have questions, we'll be happy to try to help. Cheers, Elizabeth -- == Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." == -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On Fri, 20 Aug 2010 09:47:30 +0200, 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? Why would it be boasting? I didn't say that at the age of seven I independently invented a COBOL compiler that supported recursion. *That* would be boasting. (It would also be a lie -- at the age of seven, I don't think I even knew about the existence of computers.) Boasting about understanding the idea of recursion is kind of like boasting about the putting my hands in the correct glove nine times out of ten. [...] > The fact, that you didn't have the issue doens't mean it's easy for > others. Apparently not. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On Fri, 20 Aug 2010 17:23:23 +0200, Bruno Desthuilliers wrote: > 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, FSM? Flying Spaghetti Monster? > polymorphism, hashtables, linked lists, > ADTs, algorithm complexity etc... Was there anything they *did* understand, or did they just bang on the keyboard at random until the code compiled? *wink* > Needless to say, I didn't last long !-) And rightly so :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Fri, 20 Aug 2010 11:01:42 -0700, Russ P. wrote: > Most programmers probably never use vectors and matrices, so they don't > care about the inconsistency with standard mathematical notation. Perhaps you should ask the numpy programmers what they think about that. Vectors and matrices are just arrays, and the suggestion that most programmers don't use arrays (or array-like objects like lists) is ludicrous. > 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. Only if your aim is to reduce the learning curve for newbies and non- programmers, at the expense of making it easier for them to produce buggy code. That's a defensible choice. I'm a great fan of Apple's Hypercard from the late 80s and early 90s, and it used one-based indexing, as well as English-like syntax like: put char 2 of the third word of it into the last field You don't need to know a thing about the language to guess what that does, and you'd probably be right. It would have been inappropriate for Hypercard to use zero-based indexing, because it was aimed at giving non- programmers a shallow learning curve and syntax that looks like natural language. There is room in the world for programming languages aimed at non- programmers (although HC is an extreme case), but not all languages should prefer the intuition of non-programmers over other values. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Fri, 20 Aug 2010 09:21:25 +0200, Kai Borgolte wrote: > 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? As AK pointed out, I totally messed up the example by talking about column 4 then giving an example of column 5. Sigh. 0123456789 spam > 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./ I don't see what PEP 8 has to do with anything here. Code is not the only thing that needs indenting, and 4 was just a mere example chosen at random. I might be pretty-printing a table of numbers, I might be drawing a text-based maze, I could be writing a function to left-fill strings with some arbitrary character, e.g left-fill with asterisks: 01234567 spam Besides, PEP 8 is merely a coding standard, not a law of nature. Some people might choose other coding standards, such as two-space indents, eight-spaces, or even (gasp! horror!) tabs. > And of course your text editor will number the columns beginning with > one, so the string starts at column 5. Ah, text editors. I'm glad you mention that... My text editor of choice is kwrite, which suits me fine, but it has one obnoxious, painful design choice. It indexes characters from one, so when I have the cursor at the left-hand margin and haven't typed anything, it says I'm at position 1. Consequently, if I want to know how many characters are in a line (and you'd be amazed how frequently I need to do this!), I can't just glance at the cursor position, I have to remember to subtract one from whatever the cursor position says. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On Fri, 20 Aug 2010 16:42:26 -0700, Baba wrote:
> 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:
I would disagree in part with nearly all of these.
> - a procedure is said to be recursive when it contains a statement that
> calls itself
Not necessarily.
A function can be indirectly recursive -- function f can call function g
which calls function h which calls function f. This is still recursion,
even though f doesn't contain a statement which 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
I agree with this, although I've never heard the name "Base Case" before.
> - 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.
That's so vague as to be almost meaningless. I think what you are talking
about is one specific part of memory, the calling stack, which fills up
with arguments needed to call the function, and then empties as the
recursive calls return.
However, there is an import class of recursive calls where a sufficiently
smart compiler can avoid this cost, essentially turning recursion into
iteration automatically, speeding up recursion drastically.
> - the above point means that a recursive approach is expensive on
> resources so in the practical world it should be avoided.
True-ish for the first part of the sentence, absolutely false for the
second.
Recursion can be slower and more memory consuming than iteration under
some circumstances, although this depends on the specific way that
recursion is used, not the mere fact that recursion happens. A single
recursive call is no more expensive than any other function call.
Also, as mentioned, some compilers can optimize tail-call recursion to
make it as fast and efficient as iteration. (However, Python doesn't do
this.)
In the real world, avoiding recursion also has costs. Your function may
be bigger, more complicated, need more memory, possibly manage its own
stack. None of these things happen for free. Whether a specific recursive
function is better than a specific iterative function depends on the
details of what that function does and what arguments you call it with.
If your recursive function is likely to use only a few recursive calls,
there is no need to complicate matters by re-writing it iteratively.
There's no need to avoid recursion just because it is recursive.
Also, recursion together with memoisation can be extremely fast and
efficient, at some cost of memory. For example, the typical recursive
version of factorisation:
def fact(n):
if n <= 1: return 1
return n*fact(n-1)
can be made much, much faster by giving it a simple cache:
def fact(n):
try:
cache = fact.cache
except AttributeError:
cache = fact.cache = {}
try:
return cache[n]
except KeyError:
pass
if n <= 1:
result = 1
else:
result = n*fact(n-1)
# Don't let the cache grow indefinitely large.
if len(cache) >= 100:
cache.popitem() # Discard some arbitrary item.
cache[n] = result
return result
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: String substitution VS proper mysql escaping
In message
, Νίκος
wrote:
> I would expect that:
>
> ("nikos") is a single element tuple.
Then how would you do a simple parenthesized expression?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Developer - HFT Trading firm - Chicago, IL
In message , Rich Moss wrote: > Python developer needed for math/trading applications and research at > leading HFT firm. Wasn’t HFT an exacerbating factor in just about every major stockmarket downturn since, oh, 1987? -- http://mail.python.org/mailman/listinfo/python-list
Re: Open a command pipe for reading
In message , Rodrick Brown wrote: > Sent from my iPhone 4. Glad to hear you achieved it without losing the signal. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On Aug 21, 7:37 am, John Nagle wrote: > On 8/20/2010 1:17 PM, John Bokma wrote: > > > I think you mean tail recursion optimization / elimination. > > Python does tail recursion: > > Not very well. > > def cnt(n) : > if n > 0 : > cnt(n-1) > Hi John I'm intrigued by this example. Is there something missing in the code? When i run it i get: I suppose it is meant to print a sequence of numbers from n down to zero? re tail recursion, on wiki i found: "With tail recursion, there is no need to remember the place we are calling from—instead, we can leave the stack alone, and the newly called function will return its result directly to the original caller. Converting a call to a branch or jump in such a case is called a tail call optimization. " not sure i understand that... is this bit of theory applicable to your cnt function above? tnx Baba -- 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 writes: > 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?! It is my experience that in particular graduated (and in particular Phd) computer scientists don't waste their time _applying_ that junk. They have learnt to analyze it, they could tell you how bad their own algorithms are (if they actually bothered applying their knowledge), but it does not occur to them to replace them by better ones. Or even factor their solutions in a way that the algorithms and data structures are actually isolated. I think there must be some programmer gene. It is not enough to be able to recognize O(n^k) or worse (though it helps having a more exact rather than a fuzzy notion of them _if_ you have that gene). You have to fear it. It has to hurt. You need to feel compassion with the CPU. It's not enough to sit there in your easychair, occasionally sucking on your pipeline and listen to its story about a hard realtime youth and its strained connection to its motherboard. When it stops, you have to see its benchmarks and feel their pain in your own backplane. -- David Kastrup -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On 08/21/10 04:35, Baba wrote: On Aug 21, 7:37 am, John Nagle wrote: On 8/20/2010 1:17 PM, John Bokma wrote: I think you mean tail recursion optimization / elimination. Python does tail recursion: Not very well. def cnt(n) : if n> 0 : cnt(n-1) I'm intrigued by this example. Is there something missing in the code? When i run it i get: I suppose it is meant to print a sequence of numbers from n down to zero? Sounds like you merely executed: >>> cnt which just asks what "cnt" is (in this case, it is as Python reports: a function named "cnt" at some given address), instead of actually *running* the function: >>> cnt(42) (function-calling is performed by the parens). re tail recursion, on wiki i found: "With tail recursion, there is no need to remember the place we are calling from—instead, we can leave the stack alone, and the newly called function will return its result directly to the original caller. Converting a call to a branch or jump in such a case is called a tail call optimization. " not sure i understand that... is this bit of theory applicable to your cnt function above? The recursive call (calling cnt(...) again) is the last instruction in the function before it would otherwise exit. A tail-recursion-aware compiler/interpreter would optimize that away. Instead of keeping track of a new stack-frame for each call (growing in stack-memory usage with each call), it would recognize that it could just reuse the current/top stack-frame to prevent stack blowouts. JohnN's observation was that Python doesn't recognize tail-recursion, and thus blows the top of the default stack-size at 999 recursive calls (a number adjustable with parameters to Python). If Python recognized tail-recursion and optimized for it, you could use any number you had the time to wait for. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On 08/21/10 03:31, Steven D'Aprano wrote: On Fri, 20 Aug 2010 17:23:23 +0200, Bruno Desthuilliers wrote: I also was the only guy around that understood "hairy" (lol) concepts like callback functions, FSM, FSM? Flying Spaghetti Monster? I'm guessing "Finite State Machines". But in a way, "Flying Spaghetti Monster" is also a bit "hairy" and hard to understand... Was there anything they *did* understand, or did they just bang on the keyboard at random until the code compiled? *wink* Accompanied by coping and pasting example code from Google results, random twiddling of the code or posting questions on newsgroups until the code compiles...a surprisingly popular technique. :-( -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: make install DESTDIR
On Saturday 21 August 2010, it occurred to aj to exclaim: > 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. Sorry, that feature slipped my mind. So, are you running $ make install DESTDIR=/home/foo/bar or are you trying to directly run setup.py? I just tried and use make worked for me. (though I was in a Python 3.2 dev source tree, not 2.6 -- maybe this was a bug that has been fixed?) -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Iterative vs. Recursive coding
Baba wrote: On Aug 21, 7:37 am, John Nagle wrote: On 8/20/2010 1:17 PM, John Bokma wrote: I think you mean tail recursion optimization / elimination. Python does tail recursion: Not very well. def cnt(n) : if n > 0 : cnt(n-1) Hi John I'm intrigued by this example. Is there something missing in the code? When i run it i get: I suppose it is meant to print a sequence of numbers from n down to zero? re tail recursion, on wiki i found: "With tail recursion, there is no need to remember the place we are calling from—instead, we can leave the stack alone, and the newly called function will return its result directly to the original caller. Converting a call to a branch or jump in such a case is called a tail call optimization. " not sure i understand that... is this bit of theory applicable to your cnt function above? tnx Baba Juding from your output, you didn't call the function, you just named it. To call it you needed to use parentheses, type something like cnt(5) The function is a do-nothing function. It makes no calculations, returns no result. Just illustrating recursion in the simplest way. Tail call optimization would work fine on that function. CPython doesn't do such optimization, however. If it did, it would convert the call at the end to a decrement and a jump. The net effect would be something like: def cnt(n) : while True: if n > 0: n = n-1 continue break Clearly that could be optimized as well. Maybe a great optimizer could turn it into: def cnt(n): pass DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On 21 Aug, 06:42, Standish P wrote: > 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. It indicates that you're asking a question that *you don't understand*. I'm continually amazed that people come to Usenet, wikis, websites and other fora and ask questions that even the most basic of research (and a bit of care with terminology aka "using the right words") would show to be confused. A quick scan of the available literature on garbage collection and stacks, starting with the fundamentals, would surely show you what you need to know. > 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. > What surprises may is that anyone bothered to answer, as your question was neither "thought provoking" nor in need of attention from an expert. Their generosity in the face of so much stupidity stands out as remarkable. -- http://mail.python.org/mailman/listinfo/python-list
Re: make install DESTDIR
> 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. So what is the point of your messages? Do you want to report a problem? Are you asking for help? Do you want to vent frustration? Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading the access attributes of directories in Windows
On Aug 21, 8:10 am, Tim Golden wrote:
> 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
Tim,
I appreciate the time and effort that you are putting in this post.
Personally, I am impressed of the power of python, your winsys
library, and overall, how easy it is to customize the scripting of
one's day to day needs.
I have started testing your first script
from winsys import fs, security
root = fs.dir ("c:/")
for d in root.dirs (ignore_access_errors=True):
print (d, "=>", d.security ())
Howwvwer, I am getting an error:
>>> RESTART
>>>
c:\$recycle.bin\ => O:BAD:PAI(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)(A;;0x1201ad;;;BU)
c:\aeat\ => O:BAD:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)
(A;OICIIOID;SDGXGWGR;;;AU)
c:\archivos de programa\ => O:SYD:PAI(D;;CC;;;WD)(A;;0x1200a9;;;WD)
(A;;FA;;;SY)(A;;FA;;;BA)
c:\documents and settings\ => O:SYD:PAI(D;;CC;;;WD)(A;;0x1200a9;;;WD)
(A;;FA;;;SY)(A;;FA;;;BA)
c:\hp\ => O:SYD:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)
(A;OICIIOID;SDGXGWGR;;;AU)
Traceback (most recent call last):
File "C:/Users/Vicente/Documents/VS/Python/test6.py", line 5, in
print(d, "=>",d.security())
File "C:\Python31\lib\site-packages\winsys\fs.py", line 1044, in
security
return security.security (self, options=options)
File "C:\Python31\lib\site-packages\winsys\security.py", line 585,
in security
return Security.from_object (str (obj), obj_type, options=options)
File "C:\Python31\lib\site-packages\winsys\security.py", line 475,
in from_object
sd = wrapped (win32security.GetNamedSecurityInfo, obj,
object_type, options)
File "C:\Python31\lib\site-packages\winsys\exc.py", line 55, in
_wrapped
raise exception (errno, errctx, errmsg)
winsys.security.x_security: (5, 'GetNamedSecurityInfo', 'Acceso
denegado.')
>>>
I am using a system in the Spanish language. As you can see in the
last line, 'Acceso denegado' or 'Access denied' even though the flag
"ignore_access_errors" is set to True.
I am using python 3.1 on Windows 7. What do you think is the origin of
this problem?
Vicente Soler
--
http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On 21/08/2010 00:17, Ben Finney wrote: 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 measurablehttp://portal.acm.org/citation.cfm?id=53033>. Eh? The cited abstract does not support your conjecture. I am rather more taken with the mapper/packer contrast explained in http://the-programmers-stone.com/the-original-talks/day-1-thinking-about-thinking/ 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. I agree about the lack of research. And while it is a given that some will be better than others, I suspect that research into teaching and coaching methods and cultural expectations will prove more fruitful that looking at differences between learners. Regards Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading the access attributes of directories in Windows
On Aug 21, 8:10 am, Tim Golden wrote:
> 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
Tim,
I appreciate the time and effort that you are putting in this post.
Personally, I am impressed of the power of python, your winsys
library, and overall, how easy it is to customize the scripting of
one's day to day needs.
I have started testing your first script
from winsys import fs, security
root = fs.dir ("c:/")
for d in root.dirs (ignore_access_errors=True):
print (d, "=>", d.security ())
Howwvwer, I am getting an error:
>>> RESTART
>>>
c:\$recycle.bin\ => O:BAD:PAI(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)(A;;0x1201ad;;;BU)
c:\aeat\ => O:BAD:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)
(A;OICIIOID;SDGXGWGR;;;AU)
c:\archivos de programa\ => O:SYD:PAI(D;;CC;;;WD)(A;;0x1200a9;;;WD)
(A;;FA;;;SY)(A;;FA;;;BA)
c:\documents and settings\ => O:SYD:PAI(D;;CC;;;WD)(A;;0x1200a9;;;WD)
(A;;FA;;;SY)(A;;FA;;;BA)
c:\hp\ => O:SYD:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)
(A;OICIIOID;SDGXGWGR;;;AU)
Traceback (most recent call last):
File "C:/Users/Vicente/Documents/VS/Python/test6.py", line 5, in
print(d, "=>",d.security())
File "C:\Python31\lib\site-packages\winsys\fs.py", line 1044, in
security
return security.security (self, options=options)
File "C:\Python31\lib\site-packages\winsys\security.py", line 585,
in security
return Security.from_object (str (obj), obj_type, options=options)
File "C:\Python31\lib\site-packages\winsys\security.py", line 475,
in from_object
sd = wrapped (win32security.GetNamedSecurityInfo, obj,
object_type, options)
File "C:\Python31\lib\site-packages\winsys\exc.py", line 55, in
_wrapped
raise exception (errno, errctx, errmsg)
winsys.security.x_security: (5, 'GetNamedSecurityInfo', 'Acceso
denegado.')
>>>
I am using a system in the Spanish language. As you can see in the
last line, 'Acceso denegado' or 'Access denied' even though the flag
"ignore_access_errors" is set to True.
I am using python 3.1 on Windows 7. What do you think is the origin of
this problem?
Vicente Soler
--
http://mail.python.org/mailman/listinfo/python-list
weakref.proxy behaviour in python 3.0
Dear List, I've searched for information on this without success. Has weakref.proxy changed in Python 3? I couldn't see any note in the documentation, but the following code behaves differently on Python 2.6.1 and Python 3: import weakref class Test(object): pass realobject = Test() pobject = weakref.proxy(realobject) l = [pobject,] print(realobject in l) # On python 2.6 this prints False, on Python 3 True. Is this an expected change? Best wishes, Nicholas -- http://mail.python.org/mailman/listinfo/python-list
vpython
im trying to build visual python on slackware 64bit 13.1 and i can
not get beyond the configure stage,
...
checking whether the g++ linker (/usr/x86_64-slackware-linux/bin/ld -m
elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether to enable maintainer-specific portions of
Makefiles... no
checking for some Win32 platform... no
checking for some Mac OSX platform... no
checking for a Python interpreter with version >= 2.2... python
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory... ${prefix}/lib64/python2.6/site-
packages
checking for python extension module directory... ${exec_prefix}/lib64/
python2.6/site-packages
checking for array in python module numpy... yes
checking for headers required to compile python extensions... found
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GTKGLEXTMM... no
configure: error: gtkglextmm 1.2 is required
m...@darkstar:~/soft/scinvis/visual-5.32_release$
the thing is i have installed gtkglextmm both from source and via a
slackbuilds package script and i still get the same error,
help would be a appreciated
--
http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On 21/08/2010 01:24, Martin Gregorie wrote: 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. That takes me back to Spring 1976 and my first program that wasn't a print or a validate! (I had 9 months programming experience!). It was a costing program for a huge Bill of Materials - ideal for recursion. It was a re-write (with extra functionality) from PLAN (the 1900's assembler) to COBOL ready for a hardware migration. You are right. Recursion on the 1904 in COBOL was hard work! The result however was a great success - the new program did more than the old, ran faster, was many fewer source lines and was easier to test, so it was really profitable to write - and the customer was delighted. :) Regards Ian -- http://mail.python.org/mailman/listinfo/python-list
open two files at once
hi,
what is the simplest way to open two files (one for reading and 2nd for
writing) ?
i usually do:
with open('1') as f1:
with open('2','w') as f2:
for i in f1: do something with i
f2.write(i)
is there a simpler/better way to do this ?
--
http://mail.python.org/mailman/listinfo/python-list
Re: open two files at once
robek wrote:
> what is the simplest way to open two files (one for reading and 2nd for
> writing) ?
> i usually do:
> with open('1') as f1:
>with open('2','w') as f2:
> for i in f1: do something with i
>f2.write(i)
>
> is there a simpler/better way to do this ?
Yours is the best way to do it in Python 2.6. In particular, don't use
contextlib.nested():
http://docs.python.org/library/contextlib.html#contextlib.nested
Python 2.7 allows writing
with open(source) as f1, open(dest, "w") as f2:
# ...
saving you one level of indentation.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Reading the access attributes of directories in Windows
On 21/08/2010 1:01 PM, vsoler wrote:
Personally, I am impressed of the power of python, your winsys
library, and overall, how easy it is to customize the scripting of
one's day to day needs.
Glad you find it useful...
I have started testing your first script
from winsys import fs, security
root = fs.dir ("c:/")
for d in root.dirs (ignore_access_errors=True):
print (d, "=>", d.security ())
Howwvwer, I am getting an error:
RESTART
c:\$recycle.bin\ => O:BAD:PAI(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)(A;;0x1201ad;;;BU)
c:\aeat\ => O:BAD:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)
(A;OICIIOID;SDGXGWGR;;;AU)
c:\archivos de programa\ => O:SYD:PAI(D;;CC;;;WD)(A;;0x1200a9;;;WD)
(A;;FA;;;SY)(A;;FA;;;BA)
c:\documents and settings\ => O:SYD:PAI(D;;CC;;;WD)(A;;0x1200a9;;;WD)
(A;;FA;;;SY)(A;;FA;;;BA)
c:\hp\ => O:SYD:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)
(A;OICIIOID;SDGXGWGR;;;AU)
Traceback (most recent call last):
File "C:/Users/Vicente/Documents/VS/Python/test6.py", line 5, in
print(d, "=>",d.security())
File "C:\Python31\lib\site-packages\winsys\fs.py", line 1044, in
security
return security.security (self, options=options)
File "C:\Python31\lib\site-packages\winsys\security.py", line 585,
in security
return Security.from_object (str (obj), obj_type, options=options)
File "C:\Python31\lib\site-packages\winsys\security.py", line 475,
in from_object
sd = wrapped (win32security.GetNamedSecurityInfo, obj,
object_type, options)
File "C:\Python31\lib\site-packages\winsys\exc.py", line 55, in
_wrapped
raise exception (errno, errctx, errmsg)
winsys.security.x_security: (5, 'GetNamedSecurityInfo', 'Acceso
denegado.')
I am using a system in the Spanish language. As you can see in the
last line, 'Acceso denegado' or 'Access denied' even though the flag
"ignore_access_errors" is set to True.
I am using python 3.1 on Windows 7. What do you think is the origin of
this problem?
Vicente Soler
Can you run Python from within a Run-As-Administrator command
prompt? Windows Vista & 7 bring a lot more security to the basic
Windows model. If you can't do that, it might be possible to
elevate your privileges enough to read the security attributes
using the security.change_privileges function.
TJG
--
http://mail.python.org/mailman/listinfo/python-list
Re: Reading the access attributes of directories in Windows
On 21/08/2010 1:01 PM, vsoler wrote: I am using a system in the Spanish language. As you can see in the last line, 'Acceso denegado' or 'Access denied' even though the flag "ignore_access_errors" is set to True. Sorry, meant to reply to this point as well. The ignore_access_errors flag only applies to finding the file's existence in the first place (it's a flag to the dirs iterator) but you're getting access denied on the attempt to read security. If the option to run in an Administrator-enabled windows isn't applicable, you've got a couple more options open: you could catch that specific error in a try-except block and do something which made sense in your context (write it to a log, discard it, whatever). You wouldn't get the information but it wouldn't stop you proceeding. As an alternative you could ask for slightly less information from the security () function. By default it requests Owner and DACL info; if you only wanted the DACL you can just pass "D" as the options parameter to the call. Obviously, if it's the request for DACL which is giving the access error then this won't help. Another alternative is to enable any privileges in your access token which aren't enabled by default. The likelihood is that, without running in Admin mode, the disabled privs won't offer you much. You can see what privileges you currently have by looking at your process token: from winsys import security security.token ().dump () Look for the set of privileges: an asterisk (*) means the priv is enabled by default; a plus (+) means it has been enabled; a minus (-) means it has not been enabled. If you had backup privilege enabled you would be able to read the security of any filesystem object even if you had no rights to it. TJG -- http://mail.python.org/mailman/listinfo/python-list
comp.lang.python
www.127760.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: weakref.proxy behaviour in python 3.0
On Aug 21, 1:13 pm, Nicholas Cole wrote: > I've searched for information on this without success. Has > weakref.proxy changed in Python 3? I couldn't see any note in the > documentation, but the following code behaves differently on Python > 2.6.1 and Python 3: > > import weakref > class Test(object): pass > > realobject = Test() > pobject = weakref.proxy(realobject) > l = [pobject,] > > print(realobject in l) # On python 2.6 this prints False, on Python 3 True. So the change underlying what you're seeing is that comparisons in 3.x 'unwrap' the proxy, while in 2.x they don't: Python 2.7 (r27:82500, Aug 15 2010, 14:21:15) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import weakref >>> s = set() >>> s == weakref.proxy(s) False Python 3.1.2 (r312:79147, Aug 20 2010, 20:06:00) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import weakref >>> s = set() >>> s == weakref.proxy(s) True It looks to me as though this could be a long-standing defect in Python 2.x, unwittingly(?) corrected in Python 3.x when 3-way comparisons were removed in favour of rich comparisons. See http://svn.python.org/view?view=rev&revision=51533 For 2.7, the proxy source (in Objects/weakrefobject.c) defines a 'proxy_compare' function that's used in the 'tp_compare' slot for proxy objects, and that proxy_compare function has code to unwrap the proxy objects when necessary so that comparisons are done on the real underlying objects. *But* C-level tp_compare slots only ever get called when both objects have the same type, so when comparing a real object with the proxy for that object, that's never. In 3.x, that's replace with a proxy_richcompare function for the tp_richcompare slot. So my guess is that the change was unintentional. It's probably worth a bug report. Even if the behaviour isn't going to change in either 2.x or 3.x (and it probably isn't), it might be possible to clarify the docs. -- Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: weakref.proxy behaviour in python 3.0
On Sat, Aug 21, 2010 at 3:31 PM, Mark Dickinson wrote: [SNIP] > So my guess is that the change was unintentional. > > It's probably worth a bug report. Even if the behaviour isn't going > to change in either 2.x or 3.x (and it probably isn't), it might be > possible to clarify the docs. Dear Mark, I think the docs should be fixed: it would be good to have a list of key examples where the behaviour is different. Although the new behaviour is better, it certainly tripped me up badly. I'm happy to fill a report out, but since you seem to know much more about the internals, I wonder if a bug report written by you would be more useful! Just in case it helps, one thing that does seem to be the case is that two different proxy objects to the same real object get compared in the same way on both versions. So this code: a = weakref.proxy(the_real_object) b = weakref.proxy(the_real_object) this_list = [ a, ] l.remove(a) # Obviously works on both - just here for clarity. l.remove(the_real_object) # Fails on python 2.6 l.remove(b) # gives an empty list on python 2.6 and python 3. Very best wishes, Nicholas -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On Aug 21, 5:29 am, Alex McDonald wrote: > On 21 Aug, 06:42, Standish P wrote: > > 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. > > What surprises may is that anyone bothered to answer, as your question > was neither "thought provoking" nor in need of attention from an > expert. Their generosity in the face of so much stupidity stands out > as remarkable. I wouldn't call the OP "stupid," which is just mean-spirited. That is not much of a welcome wagon for somebody who might learn Forth eventually and join our rather diminished ranks. Lets go with "over- educated" instead! I thought that his question was vague. It seemed like the kind of question that students pose to their professor in class to impress him with their thoughtfulness, so that he'll forget that they never did get any of their homework-assignment programs to actually work. I yet maintain that writing programs is what programming is all about. I see a lot of pseudo-intellectual blather on comp.lang.forth. The following is a pretty good example, in which Alex mixes big pseudo- intellectual words such as "scintilla" with gutter language such as "turd" in an ungrammatical mish-mash --- and defends the overuse of the return stack for holding temporary data as being readable(?!): http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4b9f67406c6852dd/0218831f02564410 On Jul 23, 4:43 pm, Alex McDonald wrote: > Whereas yours contained several tens, and nearly every one of them is > wrong. Hugh, do you actually have any evidence -- even a scintilla -- > that supports this log winded opinions-as-fact post? Take any of the > statements you make, and demonstrate that you can justify it. > Reminding us that you said it before doesn't count. > > Start with this turd of an assertion and see if you can polish it; > "Most of the time, when Forth code gets really ugly, it is because of > an overuse of >R...R> --- that is a big reason why people use GCC > rather than Forth." -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On 08/21/2010 03:03 AM, Steven D'Aprano wrote: >> - 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 > > I agree with this, although I've never heard the name "Base Case" before. "Base Case" is indeed the formal term. If I recall this term comes from inductive mathematical proofs, upon which recursion is based formally. In my introduction to computer data structures class we spent a lot of time learning about induction and doing inductive proofs. I always hated them until one day when I was trying to teach recursion to a group of freshmen and found myself relying on inductive proofs to demonstrate that recursion indeed works. For the uninitiated, recursion is often thought about too deeply. -- http://mail.python.org/mailman/listinfo/python-list
I HACK $3500 FROM PAYPAL...
I HACK $3500 FROM PAYPAL At http://quickpaypalmoney.tk i have hidden the PAYPAL FORM link in an image. in that website on Right Side below search box, click on image and enter your name and PAYPAL ID. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Developer - HFT Trading firm - Chicago, IL
On Aug 21, 2:30 am, Lawrence D'Oliveiro wrote: > Wasn’t HFT an exacerbating factor in just about every major stockmarket > downturn since, oh, 1987? IMO, it was a mitigating factor. HFT firms provide liquidity and help price discovery. Investor sentiment is what drives rallys and crashes. Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Developer - HFT Trading firm - Chicago, IL
On 8/21/2010 10:32 AM Raymond Hettinger said... On Aug 21, 2:30 am, Lawrence D'Oliveiro wrote: Wasn’t HFT an exacerbating factor in just about every major stockmarket downturn since, oh, 1987? IMO, it was a mitigating factor. HFT firms provide liquidity and help price discovery. Investor sentiment is what drives rallys and crashes. Mitigating? Trading applications that allow order-of-magnitude bad data through causing automated trading systems to follow suit dumping stock at a loss of billions sounds more like an instigating factor. http://www.nytimes.com/2010/05/07/business/economy/07trade.html Investor sentiment _should be_ what drives rallys and crashes, and likely is over extended periods, but appears no longer to be the only factor in market volatility. Emile -- http://mail.python.org/mailman/listinfo/python-list
logging module -> Miss messages if don't flush constantly? How set to flush constantly?
It looks like I can miss some logging messages if I don't flush after every oneis that true? This is an issue when program crashes so that logger didn't get a chance to print everything. Is there some way to set logging to constantly flush? -- http://mail.python.org/mailman/listinfo/python-list
Re: logging module -> Miss messages if don't flush constantly? How set to flush constantly?
Chris Seberino wrote: > It looks like I can miss some logging messages if I don't flush after > every oneis that true? As far as I can tell from the 2.6 source the StreamHandler does flush after each record. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On 21 Aug, 17:58, Hugh Aguilar wrote: > On Aug 21, 5:29 am, Alex McDonald wrote: > > > On 21 Aug, 06:42, Standish P wrote: > > > 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. > > > What surprises may is that anyone bothered to answer, as your question > > was neither "thought provoking" nor in need of attention from an > > expert. Their generosity in the face of so much stupidity stands out > > as remarkable. > > I wouldn't call the OP "stupid," which is just mean-spirited. Perhaps I'm just getting less forgiving the older I get, or the more I read here. The internet is a fine resource for research, and tools like google, archivx and so on are easy to access and take but a little effort to use. > That is > not much of a welcome wagon for somebody who might learn Forth > eventually and join our rather diminished ranks. I care neither to be included in your "diminished ranks", nor do I take much regard of popularity as you define it. Standish P doesn't want to join anything; he (like you) has an agenda for yet another club with a membership of one. > Lets go with "over- > educated" instead! I thought that his question was vague. It seemed > like the kind of question that students pose to their professor in > class to impress him with their thoughtfulness, so that he'll forget > that they never did get any of their homework-assignment programs to > actually work. It didn't work. He hasn't done any homework, neither do you, and it shows. > I yet maintain that writing programs is what > programming is all about. You remind me of those that would build a house without an architect, or fly without bothering to study the weather. > > I see a lot of pseudo-intellectual blather on comp.lang.forth. The > following is a pretty good example, in which Alex mixes big pseudo- > intellectual words such as "scintilla" "Scintilla" gets about 2,080,000 results on google; "blather" gets about 876,000 results. O Hugh, you pseudo-intellectual you! > with gutter language such as > "turd" About 5,910,000 results. It has a long history, even getting a mention in the Wyclif's 13th century bible. > in an ungrammatical mish-mash --- and defends the overuse of > the return stack for holding temporary data as being readable(?!): I did? Where? You're making stuff up. Again. > http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4... > > On Jul 23, 4:43 pm, Alex McDonald wrote: > > > Whereas yours contained several tens, and nearly every one of them is > > wrong. Hugh, do you actually have any evidence -- even a scintilla -- > > that supports this log winded opinions-as-fact post? Take any of the > > statements you make, and demonstrate that you can justify it. > > Reminding us that you said it before doesn't count. > > > Start with this turd of an assertion and see if you can polish it; > > "Most of the time, when Forth code gets really ugly, it is because of > > an overuse of >R...R> --- that is a big reason why people use GCC > > rather than Forth." > Something you never did address, probably because the statement you made is just another symptom of Aguilar's Disease; presenting as fact an opinion based on personal experience, limited observation and no research. -- http://mail.python.org/mailman/listinfo/python-list
Detect string has non-ASCII chars without checking each char?
Python 2.6: Is there a built-in way to check if a Unicode string has non-ASCII chars without having to check each char in the string? Here's my use case: I have a section of code that makes frequent calls to hasattr. The attribute name being tested is derived from incoming data which at times can contain international content. hasattr() raises an exception when passed a Unicode attribute name. I would have expected a simple True/False return value vs. an encoding error. UnicodeEncodeError: 'ascii' codec can't encode character u'\u012c' in position 0: ordinal not in range(128) Is this behavior by design or could I be encoding the string I'm passing hasattr() incorrectly? If its by design, I'm thinking the best approach for me would be to write a hasattr_enhanced() function that traps the Unicode encoding exception and returns False and use this function in place of hasattr(). Any thoughts on this strategy? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: weakref.proxy behaviour in python 3.0
On Aug 21, 5:06 pm, Nicholas Cole wrote: > On Sat, Aug 21, 2010 at 3:31 PM, Mark Dickinson wrote: > > [SNIP] > > > So my guess is that the change was unintentional. > > > It's probably worth a bug report. Even if the behaviour isn't going > > to change in either 2.x or 3.x (and it probably isn't), it might be > > possible to clarify the docs. > > I think the docs should be fixed: it would be good to have a list of > key examples where the behaviour is different. Although the new > behaviour is better, it certainly tripped me up badly. > > I'm happy to fill a report out, but since you seem to know much more > about the internals, I wonder if a bug report written by you would be > more useful! http://bugs.python.org/issue9658 Please do log in and add any extra comments you feel appropriate. -- Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterative vs. Recursive coding
On 8/21/2010 10:08 AM, Michael Torrie wrote: On 08/21/2010 03:03 AM, Steven D'Aprano wrote: - 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 I agree with this, although I've never heard the name "Base Case" before. "Base Case" is indeed the formal term. If I recall this term comes from inductive mathematical proofs, upon which recursion is based formally. In my introduction to computer data structures class we spent a lot of time learning about induction and doing inductive proofs. I always hated them until one day when I was trying to teach recursion to a group of freshmen and found myself relying on inductive proofs to demonstrate that recursion indeed works. For the uninitiated, recursion is often thought about too deeply. If you want to think about it deeply, read Abelson and Sussman. (http://mitpress.mit.edu/sicp/). Realistically, recursion isn't that important in Python. It's there if you need it, and sometimes useful, but generally not used much without good reason. In some functional languages, recursion is routinely used in place of iteration, but Python isn't built for that. In Python, most of the use cases for trivial recursion are better handled with iteration or generators. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Detect string has non-ASCII chars without checking each char?
2010/8/21 :
> Python 2.6: Is there a built-in way to check if a Unicode string has
> non-ASCII chars without having to check each char in the string?
>
> Here's my use case: I have a section of code that makes frequent calls to
> hasattr. The attribute name being tested is derived from incoming data which
> at times can contain international content.
>
> hasattr() raises an exception when passed a Unicode attribute name. I would
> have expected a simple True/False return value vs. an encoding error.
>
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u012c' in
> position 0: ordinal not in range(128)
>
> Is this behavior by design or could I be encoding the string I'm passing
> hasattr() incorrectly?
>
> If its by design, I'm thinking the best approach for me would be to write a
> hasattr_enhanced() function that traps the Unicode encoding exception and
> returns False and use this function in place of hasattr(). Any thoughts on
> this strategy?
>
> Thank you,
> Malcolm
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
Hi,
I can't comment on the mentioned usecase, but for checking the basic
ascii unicode strings one can maybe use a simple hack (not sure about
possible drawbacks ...)
It is likely working with all characters too, but maybe in a more
straightforward way...
>>> a = u"abc"
>>> b = u"abc\u012c"
>>> a.encode("ascii", "ignore").decode("ascii") == a
True
>>> b.encode("ascii", "ignore").decode("ascii") == b
False
>>>
Others may supply more general/elegant/... approaches.
vbr
--
http://mail.python.org/mailman/listinfo/python-list
psycopg2 for insertion of binary data to PostgreSQL database
Hello everybody out there using python,
For the insertion of pictures into my PostgreSQL database [with table
foo created by SQL command "CREATE TABLE foo (bmp BYTEA)], I've written
the following script:
#!/usr/bin/python
import psycopg2
try:
conn = psycopg2.connect("dbname='postgres' user='postgres'
host='localhost' password='data'");
except:
print "I am unable to connect to the database"
cur = conn.cursor()
f = open("test.bmp", 'rb')
myfile = f.read()
try:
cur.execute("INSERT INTO foo VALUES (%s)",(buffer(myfile),))
except:
print "Insert unsuccessful"
"python script.py" runs the script without any errors or messages.
However, the SQL command "SELECT * FROM foo" returns the output "foo (0
rows)" with no entries in the table.
I'm using Python 2.7 and PostgreSQL 8.3.
Could anyone help me to find a way to pin down the problem?
Thanks in advance,
Julia
--
http://mail.python.org/mailman/listinfo/python-list
Re: psycopg2 for insertion of binary data to PostgreSQL database
On Sat, 21 Aug 2010 22:58:00 +0200
Julia Jacobson wrote:
> For the insertion of pictures into my PostgreSQL database [with table
> foo created by SQL command "CREATE TABLE foo (bmp BYTEA)], I've written
> the following script:
>
> #!/usr/bin/python
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres'
> host='localhost' password='data'");
> except:
> print "I am unable to connect to the database"
First, bare excepts are a bad idea. Figure out what exception you
expect to catch and catch that one.
In this case, start by removing the try/except altogether and see what
the traceback says. That may explain your problem right off the bat.
If it doesn't then repost with the traceback.
--
D'Arcy J.M. Cain | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
--
http://mail.python.org/mailman/listinfo/python-list
Re: psycopg2 for insertion of binary data to PostgreSQL database
Julia Jacobson wrote:
> Hello everybody out there using python,
>
> For the insertion of pictures into my PostgreSQL database [with table
> foo created by SQL command "CREATE TABLE foo (bmp BYTEA)], I've written
> the following script:
>
> #!/usr/bin/python
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres'
> host='localhost' password='data'");
> except:
> print "I am unable to connect to the database"
> cur = conn.cursor()
> f = open("test.bmp", 'rb')
> myfile = f.read()
> try:
> cur.execute("INSERT INTO foo VALUES (%s)",(buffer(myfile),))
> except:
> print "Insert unsuccessful"
>
> "python script.py" runs the script without any errors or messages.
> However, the SQL command "SELECT * FROM foo" returns the output "foo (0
> rows)" with no entries in the table.
> I'm using Python 2.7 and PostgreSQL 8.3.
> Could anyone help me to find a way to pin down the problem?
Perhaps you need to conn.commit() your changes.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pop return from stack?
On Aug 20, 6:41 pm, Gregory Ewing wrote: > 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 Thanks Greg. That makes a lot of sense ... for the next program I write :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Developer - HFT Trading firm - Chicago, IL
In message , Raymond Hettinger wrote: > On Aug 21, 2:30 am, Lawrence D'Oliveiro > wrote: > >> Wasn’t HFT an exacerbating factor in just about every major stockmarket >> downturn since, oh, 1987? > > IMO, it was a mitigating factor. > HFT firms provide liquidity and help price discovery. > Investor sentiment is what drives rallys and crashes. Someone who doesn’t understand how positive feedback can lead to instabilities in a dynamical system. -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
David Kastrup writes: > John Passaniti writes: > >> 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?! > > It is my experience that in particular graduated (and in particular Phd) > computer scientists don't waste their time _applying_ that junk. Question: do you have a degree in computer science? Since in my experience: people who talk about their experience with graduated people often missed the boat themselves and think that reading a book or two equals years of study. Oh, and rest assured, it works both ways: people who did graduate are now and then thinking it's the holy grail and no body can beat it with home study. Both are wrong, by the way. -- 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: Iterative vs. Recursive coding
John Nagle writes: > 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. Based on your reply that follows, I agree. > 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. I agree: so this means that Python should eliminate / optimize tail recursion. To me, the current value seems a bit low, but I know nothing about Python internals. -- 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: Python Developer - HFT Trading firm - Chicago, IL
Possibly relevant: http://www.nanex.net/FlashCrash/FlashCrashAnalysis_NBBO.html On Sat, Aug 21, 2010 at 4:22 PM, Lawrence D'Oliveiro wrote: > In message > , > Raymond > Hettinger wrote: > > > On Aug 21, 2:30 am, Lawrence D'Oliveiro > > > wrote: > > > >> Wasn’t HFT an exacerbating factor in just about every major stockmarket > >> downturn since, oh, 1987? > > > > IMO, it was a mitigating factor. > > HFT firms provide liquidity and help price discovery. > > Investor sentiment is what drives rallys and crashes. > > Someone who doesn’t understand how positive feedback can lead to > instabilities in a dynamical system. > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple Python Sandbox
Stephen Hansen wrote: 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 Note that you can install an __import__ function in the builtins to provide this kind of functionality while still allowing scripts to use the normal import syntax. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: array manipulation-
Aram Ter-Sarkissov wrote: I have an array (say, mat=rand(3,5)) from which I 'pull out' a row (say, s1=mat[1,]). The problem is, the shape of this row s1 is not [1,5], as I would expect, but rather [5,], which means that I can't, for example, concateante mat and s1 rowwise. Use a 2D slice: >>> a = array([[1,2],[3,4]]) >>> a array([[1, 2], [3, 4]]) >>> b = a[1:2,:] >>> b array([[3, 4]]) >>> b.shape (1, 2) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Developer - HFT Trading firm - Chicago, IL
Lawrence D'Oliveiro wrote: Someone who doesn’t understand how positive feedback can lead to instabilities in a dynamical system. Let's hope the person they hire makes it his first task to introduce a big dollop of negative feedback into the system! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Roy Smith wrote: 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. I don't think proportional spacing is necessarily a problem, as long as a font is used that makes all characters clearly distinguishible. Unfortunately, most of the widely-used sans-serif proportional fonts fail to do this. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Gregory Ewing wrote: Roy Smith wrote: 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. I don't think proportional spacing is necessarily a problem, as long as a font is used that makes all characters clearly distinguishible. Unfortunately, most of the widely-used sans-serif proportional fonts fail to do this. I don't think proportional spacing is necessarily a problem, as long all the characters are the same width. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple Python Sandbox
On 8/21/10 5:56 PM, Gregory Ewing wrote: > Stephen Hansen wrote: > >> 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 > > Note that you can install an __import__ function in the > builtins to provide this kind of functionality while still > allowing scripts to use the normal import syntax. I really don't know why I didn't think of that to start with. Doh. Thanks :) -- 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: Iterative vs. Recursive coding
On Sat, 21 Aug 2010 19:09:52 -0500, John Bokma wrote: > this means that Python should eliminate / optimize tail > recursion. There have been various suggestions to add tail recursion optimization to the language. Two problems: * It throws away information from tracebacks if the recursive function fails; and * nobody willing to do the work is willing to champion it sufficiently to get it approved in the face of opposition due to the above. If you're like me, you're probably thinking that the traceback from an exception in a recursive function isn't terribly useful. Who needs to see something like this? >>> recurse(10) Traceback (most recent call last): File "", line 1, in File "", line 3, in recurse File "", line 3, in recurse File "", line 3, in recurse File "", line 3, in recurse File "", line 3, in recurse File "", line 3, in recurse File "", line 3, in recurse File "", line 3, in recurse File "", line 3, in recurse File "", line 2, in recurse ValueError *yawn* Would it really matter if Python truncated the stack trace to just the last line? I don't think so. But this is not the only sort of tail-call recursion, and a traceback like the following is useful: >>> recurse(4) Traceback (most recent call last): File "", line 1, in File "", line 5, in recurse File "", line 3, in f File "", line 5, in recurse File "", line 3, in f File "", line 5, in recurse File "", line 3, in f File "", line 4, in recurse File "", line 2, in g ValueError If all you saw was the last line (the call to g), debugging the exception would be significantly harder. That's a real traceback, by the way, not faked, although it is a contrived example which I shan't bother to share. The point is not my specific recursive example, but that not all recursion is direct and therefore losing the stack traces can be a real cost. There's more information here: http://www.tratt.net/laurie/tech_articles/articles/tail_call_optimization I think it says something that (so far as I know) none of the other Python implementations have added this optimization. Java doesn't have it either. Me personally, I'd like to see either a (preferably) run-time setting or compile-time switch that enables/disables this optimization. Even an explicit decorator would be fine. And lo and behold: http://hircus.wordpress.com/2008/06/21/python-tail-call-optimization-done-right/ http://groups.google.com/group/comp.lang.python/msg/9b047d1392f2b8ec Add it to your bag of tricks and have fun. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading the access attributes of directories in Windows
On Fri, 20 Aug 2010 19:41:44 +0200, Thomas Jollans wrote: >> "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? If you have append permission, you can open a file in append mode. AFAICT, this behaves the same as O_APPEND on Unix, i.e. all writes are automatically appended to the file, regardless of the current offset. Having this as a separate permission allows normal users to add entries to log files but not to erase existing entries. > Makes me wonder whether SELinux makes changes in this area, and if so, > how far-reaching they are. SELinux adds finer-grained permissions (e.g. append is distinct from write), but also adds role-based checks, i.e. permissions are attached to individual programs, which limits the extent to which a bug or misfeature can be exploited. >> 3. The owner can be either a user or a group. > > What about both? A file/directory only has one owner. >> 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? Yes, although doubtless such constraints can be circumvented (if you can install software, you can use the account of anyone who uses the software). > 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 ? I don't think that the "Administrator" account is special. AFAICT, any member of the Administrators group has the same privileges. -- http://mail.python.org/mailman/listinfo/python-list
Re: vpython
kimjeng writes: > the thing is i have installed gtkglextmm both from source and via a > slackbuilds package script and i still get the same error, > help would be a appreciated You'll just have to check what it is configure actually tests for and figure out from that why your system doesn't pass. -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On Aug 21, 3:36 am, David Kastrup wrote: > > I think there must be some programmer gene. It is not enough to be able > to recognize O(n^k) or worse (though it helps having a more exact rather > than a fuzzy notion of them _if_ you have that gene). Some of the best minds in comp.lang.forth have a penchant for sarcasm - one of the reasons I always read their posts. Maybe it gets lost on the international crowd, but I love it. -Brad -- http://mail.python.org/mailman/listinfo/python-list
Re: Detect string has non-ASCII chars without checking each char?
On 8/21/2010 1:21 PM, Vlastimil Brom wrote: 2010/8/21: Python 2.6: Is there a built-in way to check if a Unicode string has non-ASCII chars without having to check each char in the string? Here's my use case: I have a section of code that makes frequent calls to hasattr. The attribute name being tested is derived from incoming data which at times can contain international content. Bad idea. Use a dict; don't try to pretend that an object is a dict. This isn't Javascript. Incidentally, inheriting from "dict" works, and is quite useful. class item(dict) : ... p = item() p['abc'] = 1 That wasn't in early versions of Python, which led to a style of abusing objects as if they were dictionaries. Also note that 1) spaces in attribute names can be troublesome, and 2) duplicating the name of a function or built-in attribute will override it, usually leading to unwanted results. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
Oh, I am so going to regret getting sucked into this tarpit... oh well. On Sat, 21 Aug 2010 09:58:18 -0700, Hugh Aguilar wrote: > The > following is a pretty good example, in which Alex mixes big pseudo- > intellectual words such as "scintilla" with gutter language such as > "turd" in an ungrammatical mish-mash You say that like it's a bad thing. Besides, scintilla isn't a "big pseudo-intellectual" word. It might seem so to those whose vocabulary (that's another big word, like "patronizing" and "fatuousness") is lacking, but it's really quite a simple word. It means "a spark", hence "scintillating", as in "he thinks he's quite the scintillating wit, and he's half right". It also means "an iota, a smidgen, a scarcely detectable amount", and if anyone can't see the connection between a spark and a smidgen, there's probably no hope for them. Nothing intellectual about it, let alone pseudo-intellectual, except that it comes from Latin. But then so do well more half the words in the English language. Anyway, I'm looking forward to hear why overuse of the return stack is a big reason why people use GCC rather than Forth. (Why GCC? What about other C compilers?) Me, in my ignorance, I thought it was because C was invented and popularised by the same universities which went on to teach it to millions of programmers, and is firmly in the poplar and familiar Algol family of languages, while Forth barely made any impression on those universities, and looks like line-noise and reads like Yoda. (And I'm saying that as somebody who *likes* Forth and wishes he had more use for it.) In my experience, the average C programmer wouldn't recognise a return stack if it poked him in the eye. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
