[RELEASED] Python 3.2.1 rc 1
On behalf of the Python development team, I am pleased to announce the first release candidate of Python 3.2.1. Python 3.2.1 will the first bugfix release for Python 3.2, fixing over 120 bugs and regressions in Python 3.2. For an extensive list of changes and features in the 3.2 line, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2.1 visit: http://www.python.org/download/releases/3.2.1/ This is a testing release: Please consider trying Python 3.2.1 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
That's great, but where is the list if changes? -- anatoly t. On Tue, May 17, 2011 at 9:50 PM, Georg Brandl ge...@python.org wrote: On behalf of the Python development team, I am pleased to announce the first release candidate of Python 3.2.1. Python 3.2.1 will the first bugfix release for Python 3.2, fixing over 120 bugs and regressions in Python 3.2. For an extensive list of changes and features in the 3.2 line, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2.1 visit: http://www.python.org/download/releases/3.2.1/ This is a testing release: Please consider trying Python 3.2.1 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) ___ Python-Dev mailing list python-...@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: pyjamas 0.8alpha1 release
harrismh777 harrismh...@charter.net wrote: If there is another major jump like 2.x -- 3.x in the future, Python will die. I hope you guys are aware of this. The user base might accept this thing once, but they're not going do it again... The differences between major version releases of Python are far, far less than those of PHP's _minor_ releases. Hasn't seemed to have harmed its uptake at all. -- http://mail.python.org/mailman/listinfo/python-list
Re: in search of graceful co-routines
On 18/05/2011 03:10, Terry Reedy wrote:
By default, Python iterators operate in pull mode -- consumers request a
new item when they want one. I believe .send was mostly intended to
reverse that, to operate in push mode where producers .send() a item to
a consumer when they are ready to. That is certainly true of examples I
have seen.
My first exposure was with the @inlineCallbacks decorator in twisted,
which does use it both ways...
Using .send for feedback to a provider is trickier, as the two other
posts have shown.
The closest I've found to something graceful is:
def mygenerator(*args):
for arg in args:
print yielding:,arg
result = yield arg
print returned:,result
if result is not None:
yield None
provider = mygenerator(1,2,3)
for arg in provider:
print got:,arg
if arg%2:
provider.send('hello')
However, if you do g.send(None), you still get a result back, which
feels a bit weird...
It's pretty disappointing that neither the send nor throw methods added
as part of PEP342 were provided with a parameter or variant that did
send an item but don't advance the generator.
Another option is to write an iterator class instead
of generator function. You can then give the provider a message receive
method (.send or whatever) that is decoupled from the send-next method.
Yes, that's an option I'd considered, however, with a provider class as
follows:
class Provider:
def __init__(self,*args):
self.args = args
self.current = 0
def next(self):
try:
val = self.args[self.current]
except:
raise StopIteration()
self.current += 1
print yielding:,val
return val
def send(self,value):
print returned:,value
def __iter__(self):
return self
provider = Provider(1,2,3)
for arg in provider:
print got:,arg
if arg%2:
provider.send('hello')
...but that's a lot more code, and allows one of my anti-use cases to
happen:
provider = Provider(1,2,3)
provider.send(don't want this to be possible)
The generator implementation deals with the above specific case:
File test.py, line 12, in module
provider.send('hello')
TypeError: can't send non-None value to a just-started generator
...which is, in itself, a little weird, given that it doesn't protect
against:
provider = Provider(1,2,3)
val = provider.next()
provider.send(don't want this to be possible)
provider.send(don't want this to be possible)
cheers,
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
That's great, but where is the list if changes? -- anatoly t. On Tue, May 17, 2011 at 9:50 PM, Georg Brandl ge...@python.org wrote: On behalf of the Python development team, I am pleased to announce the first release candidate of Python 3.2.1. Python 3.2.1 will the first bugfix release for Python 3.2, fixing over 120 bugs and regressions in Python 3.2. For an extensive list of changes and features in the 3.2 line, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2.1 visit: http://www.python.org/download/releases/3.2.1/ This is a testing release: Please consider trying Python 3.2.1 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) ___ Python-Dev mailing list python-...@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On May 18, 9:51 am, Roland Hutchinson my.spamt...@verizon.net wrote:
Sorry to have to contradict you, but it really is a textbook example of
recursion. Try this psuedo-code on for size:
Well and so far this thread is a textbook example of myths and
misconceptions regarding recursion :D
1. 'Recursive' is a meaningful adjective for algorithms only and not
data structures
2. Recursion is inefficient
which is a corollary to
3. Recursion is different from (more general, less efficient)
iteration
4. Recursion in 'recursion theory' aka 'computability theory' is
somehow different from recursion in programming.
Let me start with 1.
The Haskell (pseudocode) defn for lists is:
data List(t) = []|(:) t List(t)
In words, a list over type t is either empty or is made byt taking a
(smaller) list and consing (:) and element onto it
It is only given this defn that al the list functions which are (in
the sense that
most programmers understand) recursive. For example:
len [] = 0
len (x:xs) = 1 + len xs
Note that the definition of List is primary and the recursive
functions on this definition are secondary to this definition.
What happens in languages more and more far from the 'functional
purity' of Haskell?
Much the same except that implementation details muddy the waters.
eg in C the defn for list (of an elsewhere specified type t) runs thus
struct node {
t elem;
struct node *next;
}
To make the recursion more explicit, introduce the typedef:
typedef struct node *nodeptr;
struct node {
t elem;
nodeptr next;
};
And we see clearly a mutual recursion in this data type:
node contains nodeptr
nodeptr points to node
So one could say that the C defn is more recursive than the Haskell
one in the sense that double recursion is 'more recursion' than
single.
I could continue down 2,3,4 but really it may be worthwhile if the
arguers first read the wikipedia disambiguation pages on recursion...
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [RELEASED] Python 3.2.1 rc 1
For an extensive list of changes and features in the 3.2 line, see http://docs.python.org/3.2/whatsnew/3.2.html Might I presume that clicking the link would show the required changes? -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On May 18, 7:06 am, rusi rustompm...@gmail.com wrote:
On May 18, 9:51 am, Roland Hutchinson my.spamt...@verizon.net wrote:
Sorry to have to contradict you, but it really is a textbook example of
recursion. Try this psuedo-code on for size:
Well and so far this thread is a textbook example of myths and
misconceptions regarding recursion :D
1. 'Recursive' is a meaningful adjective for algorithms only and not
data structures
2. Recursion is inefficient
which is a corollary to
3. Recursion is different from (more general, less efficient)
iteration
4. Recursion in 'recursion theory' aka 'computability theory' is
somehow different from recursion in programming.
Let me start with 1.
The Haskell (pseudocode) defn for lists is:
data List(t) = [] | (:) t List(t)
In words, a list over type t is either empty or is made byt taking a
(smaller) list and consing (:) and element onto it
It is only given this defn that al the list functions which are (in
the sense that
most programmers understand) recursive. For example:
len [] = 0
len (x:xs) = 1 + len xs
Note that the definition of List is primary and the recursive
functions on this definition are secondary to this definition.
What happens in languages more and more far from the 'functional
purity' of Haskell?
Much the same except that implementation details muddy the waters.
eg in C the defn for list (of an elsewhere specified type t) runs thus
struct node {
t elem;
struct node *next;
}
To make the recursion more explicit, introduce the typedef:
typedef struct node *nodeptr;
struct node {
t elem;
nodeptr next;
};
And we see clearly a mutual recursion in this data type:
node contains nodeptr
nodeptr points to node
So one could say that the C defn is more recursive than the Haskell
one in the sense that double recursion is 'more recursion' than
single.
I could continue down 2,3,4 but really it may be worthwhile if the
arguers first read the wikipedia disambiguation pages on recursion...
No need - I have the Dictionary definition of recursion here:
Recursion: (N). See recursion.
--
http://mail.python.org/mailman/listinfo/python-list
Actresses mumaith khan old movies updated wallpapers
http://trisha4uuu.blogspot.com/2011/01/mumaith-khan-wall-papers.html mumaith khan wallpapers and photos and pictures watch and enjoy Mumaith Khan Includes mumaith khan photos, mumaith khan gossip, mumaith khan biography, mumaith khan wallpapers, mumaith khan filmography, mumaith khan videos, mumaith khan pictures. Mumaith khan facebook mumaith khan - telugupedia collaboratively authored wiki about telugu, telugu people, ugadi telugu greetings 2011, telugu films news, telugu newspapers, eenaud newspaper. Mumaith khan mumait khan hot sexy actress profile biography mumaith khan - description: mumaith khan is an indian film actress known for her item numbers she has acted in movies in hindi, telugu, tamil and kannada languages. Mumaith khan facebook mumaith khan is on facebook join facebook to connect with mumaith khan and others you may know facebook gives people the power to share and makes the world more open. Mumaith khan - telugupedia download telugu calendar 2011, ugadi hot and news mumaith khan mumaith khan wallpapers mumaith khan pictures mumaith khan photos mumaith khan hot pics.Mumaith khan mumaith khan wallpapers mumaith khan pictures mumaith khan mumait khan hot sexy actress profile biography movies psyphil celebrity. Mumaith khan mumaith khan an indian film actress who is very popular by her glamour songs she has acted in nearly 15 movies in hindi, telugu, tamil and kannada languages. Mumaith khan - ask jeeves encyclopedia why mumaith khan should be called as cameo girl as she has done almost all her movies for just item dances her dance in pokkiri got attention and no longer far she grew. Mumaith khan sexy photo tamil actress photos tamil movies mumaith khan is an indian film actress known for her item numbers she has acted in movies in hindi, telugu, tamil and kannada languages mumaith khan is 39 years old. http://trisha4uuu.blogspot.com/2011/01/mumaith-khan-wall-papers.html -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Wed, May 18, 2011 at 12:06 AM, rusi rustompm...@gmail.com wrote: 4. Recursion in 'recursion theory' aka 'computability theory' is somehow different from recursion in programming. Um, it is. Consider the simple function (lambda x, y: x + y). Mathematically, this function is recursive. Algorithmically, it is not. Do you disagree? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7 Debian 6.0. Squeeze
On Thu, May 12, 2011 at 17:27, Jorge Romero jorgeromero...@gmail.com wrote: I tried Googling about Python 2.7 on Debian Squeeze, but did not find anything but discussions -.-. Anyone out there that can point me some helpful material or anyone who had luck running 2.7 on Debian? I use pythonbrew : http://pypi.python.org/pypi/pythonbrew -- Sebastien Douche sdou...@gmail.com Twitter: @sdouche (agile, lean, python, git, open source) -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On May 18, 11:58 am, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 18, 2011 at 12:06 AM, rusi rustompm...@gmail.com wrote: 4. Recursion in 'recursion theory' aka 'computability theory' is somehow different from recursion in programming. Um, it is. Consider the simple function (lambda x, y: x + y). Mathematically, this function is recursive. Algorithmically, it is not. Do you disagree? See the definition of primitive recursion eg. http://en.wikipedia.org/wiki/Primitive_recursive_function#Definition (2 of the second set of more complex definitions) from where the name 'primitive recursion' is presumably derived) And for the more general (wider) class of 'recursive' functions (in the math sense aka computable functions) see a little below: http://en.wikipedia.org/wiki/Primitive_recursive_function#Relationship_to_recursive_functions Of course I grant that the adjective 'recursive' is used differently in computability and in programming but the roots are not all that different. If I remember right (I may be misremembering) Hofstader, referring to the invention of 'recursive function' by Godel, says something to the effect that Godel was inventing lisp 30 years before lisp... -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On May 18, 11:50 am, Harrison Hill harrish...@gmx.com wrote: Rusi wrote I could continue down 2,3,4 but really it may be worthwhile if the arguers first read the wikipedia disambiguation pages on recursion... No need - I have the Dictionary definition of recursion here: Recursion: (N). See recursion. Ha! Ha! Worth also looking at the talk page of the recursive disambiguation page: http://en.wikipedia.org/wiki/Talk:Recursive -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Mon, 16 May 2011 23:42:40 +0100, Rhodri James rho...@wildebst.demon.co.uk wrote: : ...which is, of course, not exactly secure either. A sufficiently : determined hacker won't have much trouble disassembling a shared library : even if you do strip out all the debug information. By chance I'm having : to do something closely related to this at work just at the moment; it's : hard, but far from impossible. But then, nothing is secure in any absolute sense. The best you can do with all your security efforts is to manage risk. Since obfuscation increases the cost of mounting an attack, it also reduces risk, and thereby provides some level of security. Obviously, if your threat sources are dedicated hackers or maybe MI5, there is no point bothering with obfuscation, but if your threat source is script kiddies, then it might be quite effective. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Multiple python environments (was Python 2.7 Debian 6.0. Squeeze)
On May 18, 12:05 pm, Sebastien Douche sdou...@gmail.com wrote: On Thu, May 12, 2011 at 17:27, Jorge Romero jorgeromero...@gmail.com wrote: I tried Googling about Python 2.7 on Debian Squeeze, but did not find anything but discussions -.-. Anyone out there that can point me some helpful material or anyone who had luck running 2.7 on Debian? I use pythonbrew :http://pypi.python.org/pypi/pythonbrew Interesting. Is this an alternative to virtualenv? My overall impression of this area is that there are a zillion alternatives (Well ok exaggeration -- more alternatives than needed) And all of them fail on some essential aspects. Yesterday I was trying to setup python on a client site and easy_install kept giving errors. Not easy_install printing errors but python printing backtraces. After repeatedly trying it a few times the errors disappeared. God alone knows... (or maybe Heisenberg...) -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Pascal J. Bourguignon p...@informatimago.com writes: Roland Hutchinson my.spamt...@verizon.net writes: Tail recursion can always be turned into an iteration when it is executed. All recursions can be turned into iterations, before execution. True, but only by simulating the call stack in the iterative code. To my mind that isn't really an iterative algorithm anymore if it ends up simulating the call stack. Tree walks are the canonical example of what can't be done in an iterative fashion without the addition of an explicitly managed stack -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: ipython prompt does not appear in windows
On May 18, 3:31 am, Ori L. ori.liv...@gmail.com wrote: See here for a workaround:https://bugs.launchpad.net/ipython/+bug/290228 First result on Google for the query ipython emacs windows, BTW. Thanks -- I did find that before asking. That link starts by recommending a small change (add -i flag) to ipython.bat I only find an ipython.exe (in C:\Python27|Scripts ) -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Tue, 17 May 2011 15:26:42 -0700 (PDT), Xah Lee xah...@gmail.com wrote: : If you look at Windows or Mac OS X world, i don't think they ever : refer to dealing with whole dir as “recursive” in user interface. That's purely due to a difference in the level of abstraction. Mac OS introduced its own vocabulary, of folders, where Unix and DOS talked about directories. A folder is a visual element on the screen; exactly modelling a paper folder. It goes without saying that if you bin a folder, the contents goes with it. Anything else would break the model and abstraction. On Unix, the directory is just a file, listing other files by name and disk location. Then it is perfectly natural (although very rarely smart) to delete a directory without any concequences to the contents. The data structure is clearly recursive; a file is either an ordinary file or a directory, and a directory is a list of files. An operation traversing the recursive data structure is recursive regardless of how the algorithm is specified or implemented. A large, although diminishing, fraction of Unix (excluding Mac OS) users are likely to be familiar with the recursive structure of the file system. Now Mac OS X has maintained the folder concept of older mac generations, and Windows has cloned it. They do not want the user to understand recursive data structures, and therefore, naturally, avoid the word. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Hans Georg Schaathun h...@schaathun.net writes: On Unix, the directory is just a file, listing other files by name and disk location. Then it is perfectly natural (although very rarely smart) to delete a directory without any concequences to the contents. Ironically, the only unix I know of where this makes a lot of sense is Mac OS X (where multiple hard links to a single directory is utilised by TimeMachine to minimise the size of incremental backup trees) :-) -- (espen) -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On 17 May 2011 23:42:20 -0700, Thomas A. Russ t...@sevak.isi.edu wrote: : Tree walks are the canonical example of what can't be done in an : iterative fashion without the addition of an explicitly managed stack Of course you can do it. It isn't nice, but it is possible. I assume that you refer to depth first walks, as breadth first is more easily described by iteration on a queue in the first place. Depth first can be achieved by looping over the nodes, with a state keeping references to the current and the previous node considered. By comparing the previous node (pointer or ID) to the current node's parent and children one will know wherefrom the current node was entered, and can choose the next child in the list as the next node, or the parent if all children have been visited. A visit action may be added in any or all times the node is visited. This node requires no stack. The only state space is constant, regardless of the size of the tree, requiring just the two pointers to previous and current. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand html.parser.HTMLParser
Andrew Berg, 17.05.2011 03:05: lxml looks promising, but it doesn't say anywhere whether it'll work on Python 3 or not Well, it pretty clearly states that on the PyPI page, but I also added it to the project home page now. lxml 2.3 works with any CPython version from 2.3 to 3.2. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 18, 2:33 am, Terry Reedy tjre...@udel.edu wrote: On 5/17/2011 12:07 PM, lkcl wrote: On May 4, 7:37 pm, Terry Reedytjre...@udel.edu wrote: On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote: pyjamasis a suite of projects, including a python-to-javascript compiler As you well know, there is no such thing as 'python' when it comes to compiling actual code. So please specify both in announcements here and on the project homepagehttp://sourceforge.net/projects/pyjamas/ which versions are supported. [no response] I would still like to know. Do you fully support 2.7? It has many of the same changes that are in 3.1 and even 3.2 so I can imagine it would be difficult. sorry, terry, missed this out. there are two answers: a) at the moment a http://python.org 2.N interpreter is required to actually run the translator. if you use http://python.org 2.5 or 2.6 you do not need to use the --internal-ast option. if you use 2.4, 2.7 or above, you will need to use --internal-ast because we're heavily reliant on the internal c-based compile module [without the --internal-ast option enabled]. b) the actual pyjs interpreter grammar (AST) was 2.5 but has mostly been updated to 2.6. actual python syntax / features are therefore mostly 2.5, with someone having pointed out that slice has different return results it's hard to say exactly which is best to be picked, 2.5 or 2.6. nobody's needed slice until recently, so it's not an issue that's ever come up before. the thing is - it's worth reiterating: you just... really don't need as much python interoperability for user-interfaces when they're split along MVC lines. bear in mind that it's necessary to do that split: it's web browser technology, you can't *actually* execute things like psycopg or mysql in a web browser as javascript! so once you've divided that application into python that runs the actual user interface and python on the other side of the AJAX barrier e.g. a django app you're left with a far smaller task for the pyjs interpreter to have to tackle. this is why it's been so unnecessary to keep absolutely up-to-date with the full python development that's been going on, yet we still have people developing 10,000+ LOC 2 man-year pyjamas projects. that having been said, there _is_ the requirement to be python strict as well as fast - mutually exclusive of course. and there is someone working on getting the pyjs compiler and supporting libraries into shape in order to run the entire http://python.org regression test suite. there really are quite a lot of little sub- projects within the pyjamas project. If you do not yet support 3.x, I request and recommend that you do so, with the situation as it is, there is not a snowball in hell's chance that's going to happen. allow me to explain. Thank you for the explanation. not a problem. You are right that I probably underestimated the work, yeah... i apologise for the somewhat-evident flabbergasted tone that may have been apparent in what could otherwise be considered to be a project outline / roadmap :) though you have or will do some of what is needed to fully support 2.7. weell... see above: it's kiinda unnecessary - it just depends on people's needs. if there are intelligent and willing people (like kees) who just come along and go yep, that's nice, but it's not good enough for me: i'm going to make it so then it'll happen. everyone else _not_ willing to put in the effort to make pyjs do what they want will just have to put up with the foibles. so if someone wants to do it, hell i'm not going to stand in the way - anyone who asks i give them commit rights, point them at the DEVELOPER.RULES and let them get on with it. ... otherwise please - really: just saying give me support for python 3.x or else is ... And I did not say that. yeah i know - i'm sorry: it just, with a little bit of twisting, could be construed as implying that. python 3 is the future of python gimme a break!! Let's discuss that in a couple of years. :) i think... people forget that there are now two mutually- exclusively-incompatible programming languages out there, where the first six letters of the name of the programming language happen to be the same... l. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Xah Lee xah...@gmail.com: For example, when you want to delete the whole dir in emacs, it prompts this message: “Recursive delete of xx? (y or n) ”. AFAICS what emacs calls recursive delete is what the ordinary person would simply call delete. Presumably the non-recursive delete is called simply delete but is actually something more complicated than delete, and you're supposed to know what that is. Also (I'm speculating) a recursive delete means carrying out the (ordinary, non-recursive) delete process on sub-directories, recursively. The result of which is, put simply, to delete the directory. I find all this somewhat arcane. Questioning the precise suitability of the word recursive seems like a quibble. -- Mike Barnes Cheshire, England -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 18, 6:29 am, harrismh777 harrismh...@charter.net wrote: Terry Reedy wrote: No, because I think you are exaggerating. That said, I think core Python is pretty close to 'complete' and I would not mind further syntax freezes like the one for 3.2. I am exaggerating only to the extent that someone can imagine folks becoming just annoyed with PEP progress to drop the whole thing... I am exaggerating only to the extent that we define 'it' as language death... if the user base narrows, python's future is held tentative... on the other hand, if the user base grows and campers are happy, then python's future is more stable... I don't think this is an exaggeration... one thing that people are not aware of - because it normally simply does not make its way out into the public world: you're forgetting those people who just use python. they don't get onto public mailing lists, they don't develop free software projects. i've mentioned this story before, but it's worth repeating in this context. i worked in a military environment (NC3A) back in 2006-2007. the version of python that they were using was http://python two... point... ONE. six years after its release. why??? well, it went something like this. someone got the idea that doing a portal would be good. so they looked around, and found Zope. so, they evaluated the latest version somewhere around ooo april to june of 2001. ok they _started_ evaluating it. so, some four months later, after doing some coding examples, we're now up to august 2001, a decision has to be made by the internal client. they say yep, go for it, but that took another four months (dec 2002). now we do 18 months of software development (july 2003) to produce a base package. now the code now has to be handed over to a team who perform security evaluations. this has to be paid for. another six months go by, and the security accreditation is received (dec 2004). but this was just for the base code: now we have deployment and actual product / portal development, and a maintenance cycle of 2 years (2006). now i'm called in to help with that maintenance and development cycle (2007). and throughout this time there is *no way* that they can upgrade from python 2.1, because it would cost another $EUR 10,000 to get the accreditation certificate. it's now 2011. for all i know, some TEN YEARS after python 2.1 was released, they're still using it. you ... _just_ don't normally hear about these kinds of deployments of free software, but it illustrates that a particular version can hang around for a hell of a long time. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple python environments (was Python 2.7 Debian 6.0. Squeeze)
On May 18, 12:41 pm, rusi rustompm...@gmail.com wrote: On May 18, 12:05 pm, Sebastien Douche sdou...@gmail.com wrote: On Thu, May 12, 2011 at 17:27, Jorge Romero jorgeromero...@gmail.com wrote: I tried Googling about Python 2.7 on Debian Squeeze, but did not find anything but discussions -.-. Anyone out there that can point me some helpful material or anyone who had luck running 2.7 on Debian? I use pythonbrew :http://pypi.python.org/pypi/pythonbrew Interesting. Is this an alternative to virtualenv? My overall impression of this area is that there are a zillion alternatives (Well ok exaggeration -- more alternatives than needed) And all of them fail on some essential aspects. Yesterday I was trying to setup python on a client site and easy_install kept giving errors. Not easy_install printing errors but python printing backtraces. After repeatedly trying it a few times the errors disappeared. God alone knows... (or maybe Heisenberg...) pythonbrew does not run on windows [Just recording it here to save others time if/when they reach here] -- http://mail.python.org/mailman/listinfo/python-list
Re: FW: help please
On Tue, 2011-05-17 at 21:46 -0300, Gabriel Genellina wrote: En Tue, 17 May 2011 16:48:29 -0300, Albert Hopkins mar...@letterboxes.org escribió: On Tue, 2011-05-17 at 10:18 -0600, Littlefield, Tyler wrote: Not to be pedantic or anything, and I may not be able to help regardless, but it looks like your space key is fixed, and I don't really care to pick through and try to play hangman with your message. I actually, at first glance, thought it was spam, ignored it, and was wondering why people were replying to it :| I can't remember exactly in which release 'perfect English skills' were added to Python runtime requirements, could you please refresh my memory? I can't speak for Tyler (I assume your message was meant for him) but as for myself: I saw a glob of practically unreadable text and simply passed it off as spam, concluding that any well-intentioned, moderately intelligent human being wouldn't have intentionally posted such a monstrosity and actually expected an intelligent response. I'm guessing Tyler's message was to help you so that your messages don't continue to be ignored by people who may otherwise be of assistance. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Thomas A. Russ wrote: Pascal J. Bourguignon p...@informatimago.com writes: Roland Hutchinson my.spamt...@verizon.net writes: Tail recursion can always be turned into an iteration when it is executed. All recursions can be turned into iterations, before execution. True, but only by simulating the call stack in the iterative code. To my mind that isn't really an iterative algorithm anymore if it ends up simulating the call stack. When does a data structure stop being a simulation of a stack? I've often had to turn recursive algorithms into iterative ones, where the solution turned out to be simulating the call stack only in a very broad sense; a big stretch of the imagination is needed to see the equivalent of push or pop operations. Tree walks are the canonical example of what can't be done in an iterative fashion without the addition of an explicitly managed stack Let me throw in an example where the desired tree walk is neither depth-first or breadth-first. It's to do with the way I display my family tree on my web site; an example may be found at http://www.pmoylan.org/cgi-bin/wft.cmd?D=moylan;P=I004 Most people familiar with algorithm design will, I believe, end up deciding that the appropriate data structure in this case is a queue rather than a stack. ObAUE: In common parlance, the English word recursion means pretty much the same as what computing people call iteration. This might be the first time I have ever found a point of agreement with Xah Lee. -- Peter Moylan, Newcastle, NSW, Australia. http://www.pmoylan.org For an e-mail address, see my web page. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Harrison Hill wrote: On May 18, 7:06 am, rusi rustompm...@gmail.com wrote: I could continue down 2,3,4 but really it may be worthwhile if the arguers first read the wikipedia disambiguation pages on recursion... No need - I have the Dictionary definition of recursion here: Recursion: (N). See recursion. It's interesting to note that the definitions of 'recursive' to be found in Wikipedia and Wiktionary have very little in common with the definitions to be found in the dictionaries covered by Onelook. No wonder experts in different areas have trouble communicating with one another. -- Peter Moylan, Newcastle, NSW, Australia. http://www.pmoylan.org For an e-mail address, see my web page. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On May 18, 5:09 pm, Peter Moylan inva...@peter.pmoylan.org.invalid wrote: ObAUE: In common parlance, the English word recursion means pretty much the same as what computing people call iteration. This might be the first time I have ever found a point of agreement with Xah Lee. Maybe the common usage mirrors the facts better than the lore that half-baked programmers remain devoted to. Consider first implementations: The implementation of recursion by a typical language (eg gcc for C) maximizes generality at the cost of efficiency The implementation of a very special case -- tail recursion -- in some special languages (most notably scheme) is required to be competitive with the iterative solution. [If I remember right in Chez scheme tail recursion was more efficient than a do (iteration) because a do typically needed assignment and assignment was more expensive than parameter passing] But there is a wide spectrum of cases between the most general case of recursion and tail recursion. Some examples 1 A non-tail recursive function, with a single recursive call, when implemented naively would push the return address. This is unnecessary as only a flag needs to be pushed -- return to internal call point or return to external call point. This itself can be efficiently simulated by storing the recursion depth -- zero = jump out; 0 = jump to internal call 2. A single function with double recursion -- quicksort is the classic -- can be implemented without recursion or stack. It just needs a set of pending begin-end pairs yet to be sorted. This may look like the stack in another guise but unlike the stack it does not need to store any function call return paraphernalia. 3. Tree recursion (though not the case of the OP) can be solved non- recursively with threading http://en.wikipedia.org/wiki/Threaded_binary_tree and Schorr Waite Deutsch http://www.cs.cornell.edu/courses/cs312/2007fa/lectures/lec21-schorr-waite.pdf In fact the only example I can think of where the full blown generality of recursion cannot be tightened is perhaps recursive descent parsing. So much for implementations. Semantically the while loop while B: statement is equivalent to the recursion: def stateiter(): if B: statement stateiter() -- http://mail.python.org/mailman/listinfo/python-list
Re: FW: help please
On 18/05/2011 12:47, Albert Hopkins wrote: On Tue, 2011-05-17 at 21:46 -0300, Gabriel Genellina wrote: En Tue, 17 May 2011 16:48:29 -0300, Albert Hopkins mar...@letterboxes.org escribió: On Tue, 2011-05-17 at 10:18 -0600, Littlefield, Tyler wrote Not to be pedantic or anything, and I may not be able to help regardless, but it looks like your space key is fixed, and I don't really care to pick through and try to play hangman with your message. I actually, at first glance, thought it was spam, ignored it, and was wondering why people were replying to it :| I can't remember exactly in which release 'perfect English skills' were added to Python runtime requirements, could you please refresh my memory? I can't speak for Tyler (I assume your message was meant for him) but as for myself: I saw a glob of practically unreadable text and simply passed it off as spam, concluding that any well-intentioned, moderately intelligent human being wouldn't have intentionally posted such a monstrosity and actually expected an intelligent response. I'm guessing Tyler's message was to help you so that your messages don't continue to be ignored by people who may otherwise be of assistance. Sure the English wasn't the best but there was enough information in the post to identify the likely source of the problem - with a little help from my favourite search engine - and give the guy/gal some ideas of where to look for a solution. If you were required to answer the question then asking the poster to phrase it better is going to help solve the issue faster but for a mailing list like this simply ignore it. Stuart -- http://mail.python.org/mailman/listinfo/python-list
Re: connect SIGINT to custom interrupt handler
On 2011-05-15, Miki Tebeka miki.teb...@gmail.com wrote:
Why not just catch KeyboardInterrupt?
Would it be possible to continue my program as nothing had happened in
that case (like I did before, setting a flag to tell main() to finish the
running data download and quit instead of starting the next data download
{it's a for-loop})?
I have tried it, but after catching the KeyboardInterrupt I could only
continue to the next iteration.
--
http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 18, 10:24 am, lkcl luke.leigh...@gmail.com wrote: otherwise please - really: just saying give me support for python 3.x or else is ... And I did not say that. yeah i know - i'm sorry: it just, with a little bit of twisting, could be construed as implying that. in case it wasn't clear, i apologise for doing that :) -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 17, 5:38 pm, harrismh777 harrismh...@charter.net wrote: is recompiled everything still works... not so in Python. The fact that Python is free to morph gleely from PEP to PEP without responsibility or accountability with the user base is what may kill Python, unless the Python community gets a grip on this concept. he's got a good point, terry. breaking backwards-compatibility was a completely mad and incomprehensible decision. i don't believe version N of python is going to die due to changes - the sheer inertia of hundreds of millions of lines of code and hundreds of thousands of projects will make sure that's not going to happen, but it doesn't help. it doesn't matter what the leading-edge developers behind python _want_ to happen: it took 10+ years for python 1 and 2 to gain traction, and i believe that's the sort of order of magnitude lag-time to expect people world-wide to make decisions [to replace code]. you only have to look at how long it's taking IE6 to die :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: FW: help please
On Wed, 2011-05-18 at 13:39 +0100, Stuart MacKay wrote: If you were required to answer the question then asking the poster to phrase it better is going to help solve the issue faster but for a mailing list like this simply ignore it. Which is what I've done. -- http://mail.python.org/mailman/listinfo/python-list
Re: connect SIGINT to custom interrupt handler
On May 18, 9:28 am, Christoph Scheingraber s...@scheingraber.net
wrote:
On 2011-05-15, Miki Tebeka miki.teb...@gmail.com wrote:
Why not just catch KeyboardInterrupt?
Would it be possible to continue my program as nothing had happened in
that case (like I did before, setting a flag to tell main() to finish the
running data download and quit instead of starting the next data download
{it's a for-loop})?
I have tried it, but after catching the KeyboardInterrupt I could only
continue to the next iteration.
No, since the exception being raised represents a different flow of
control
through the program, one that is mutually exclusive with the flow of
control
which would be involved with continuing the processing in the
current
iteration of your loop.
Setting SA_RESTART on SIGINT is probably the right thing to do. It's
not
totally clear to me from the messages in this thread if you managed to
get
that approach working. The most commonly encountered problem with
this
approach is that it means that any blocking (eg I/O) operation in
progress
won't be interrupted and you'll have to wait for it to complete
normally.
In this case, it sounds like this is the behavior you actually want,
though.
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
Re: Faster Recursive Fibonacci Numbers
On May 17, 9:36 am, rusi rustompm...@gmail.com wrote: On May 17, 8:50 pm, RJB rbott...@csusb.edu wrote: I noticed some discussion of recursion. the trick is to find a formula where the arguments are divided, not decremented. I've had a divide-and-conquer recursion for the Fibonacci numbers for a couple of years in C++ but just for fun rewrote it in Python. It was easy. Enjoy. And tell me how I can improve it! def fibo(n): A Faster recursive Fibonaci function Use a formula from Knuth Vol 1 page 80, section 1.2.8: If F[n] is the n'th Fibonaci number then F[n+m] = F[m]*F[n+1] + F[m-1]*F[n]. First set m = n+1 F[ 2*n+1 ] = F[n+1]**2 + F[n]*2. Then put m = n in Knuth's formula, F[ 2*n ] = F[n]*F[n+1] + F[n-1]* F[n], and replace F[n+1] by F[n]+F[n-1], F[ 2*n ] = F[n]*(F[n] + 2*F[n-1]). if n=0: return 0 elif n=2: return 1 elif n%2==0: half=n//2 f1=fibo(half) f2=fibo(half-1) return f1*(f1+2*f2) else: nearhalf=(n-1)//2 f1=fibo(nearhalf+1) f2=fibo(nearhalf) return f1*f1 + f2*f2 RJB the Lurkerhttp://www.csci.csusb.edu/dick/cs320/lab/10.html - Its an interesting problem and you are 75% there. You see the halving gives you logarithmic behavior and the double calls give exponential behavior. So how to get rid of double calls? Its quite simple: Just define your function in terms of return pairs of adjacent pairs ie (fib(n), fib(n +1)) for some n rather then a single number fib(n) Here's a straightforward linear function: def fp(n): #fibpair if n==1: return (1,1) else: a,b = fp(n-1) return (b, a+b) def fib(n): a,b = fp(n) return a --- Now use this (pairing) idea with your (halving) identities and you should get a logarithmic algo. [If you cant do it ask again but yes its fun to work out so do try :-) ] Thank you! Very cool and clear. I hoped that there was something that Python made natural I couldn't see after 50 years in other languages. I'd like to work on combining both approaches. It may take a while... -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Wed, May 18, 2011 at 1:10 AM, rusi rustompm...@gmail.com wrote: Um, it is. Consider the simple function (lambda x, y: x + y). Mathematically, this function is recursive. Algorithmically, it is not. Do you disagree? See the definition of primitive recursion eg. http://en.wikipedia.org/wiki/Primitive_recursive_function#Definition (2 of the second set of more complex definitions) from where the name 'primitive recursion' is presumably derived) And for the more general (wider) class of 'recursive' functions (in the math sense aka computable functions) see a little below: http://en.wikipedia.org/wiki/Primitive_recursive_function#Relationship_to_recursive_functions I know what primitive recursive and computable functions are, thanks. What you're failing to explain is why you would consider that function to be recursive from a programming standpoint. In programming, when we say a function is recursive, we mean that it is implemented using the technique of recursion, not that it is computable. Since we're throwing around Wikipedia links, see the definition in the first sentence at: http://en.wikipedia.org/wiki/Recursion_%28computer_science%29 In fact, the mathematical definition would not be useful for programming since to us a function is an implementation of an algorithm (I expect Lispers may quibble over this, but it is true even there). Thus, in programming, all functions are computable. Of course I grant that the adjective 'recursive' is used differently in computability and in programming but the roots are not all that different. Not just the adjective 'recursive', but also the noun 'function'. I'm not sure of the exact etymology of 'recursive', although I would bet that the mathematical usage came first and the programming usage is a derivative of it. -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, May 18, 2011 at 10:36, Hans Georg Schaathun h...@schaathun.net wrote: But then, nothing is secure in any absolute sense. The best you can do with all your security efforts is to manage risk. Since obfuscation increases the cost of mounting an attack, it also reduces risk, and thereby provides some level of security. Obviously, if your threat sources are dedicated hackers or maybe MI5, there is no point bothering with obfuscation, but if your threat source is script kiddies, then it might be quite effective. The flip side is that the developer will not know about weaknesses until much later in the development, when making changes to the underlying code organization may be difficult or impossible. In this early phase of development, he should actually encourage the script kiddies to report the bugs. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On May 18, 7:32 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 18, 2011 at 1:10 AM, rusi rustompm...@gmail.com wrote: Um, it is. Consider the simple function (lambda x, y: x + y). Mathematically, this function is recursive. Algorithmically, it is not. Do you disagree? See the definition of primitive recursion eg. http://en.wikipedia.org/wiki/Primitive_recursive_function#Definition (2 of the second set of more complex definitions) from where the name 'primitive recursion' is presumably derived) And for the more general (wider) class of 'recursive' functions (in the math sense aka computable functions) see a little below: http://en.wikipedia.org/wiki/Primitive_recursive_function#Relationshi... I know what primitive recursive and computable functions are, thanks. Myself, my memory of things studied badly decades ago may be fuzzy :D ) Anyhow taking those links to be authoritative, what I am saying is: Coming from the computability side, there are 3 related but distinct definitions of recursive: 1. Anything computable is recursive -- general recursive or partial recursive (evidently there is some dispute re these definitions http://mathworld.wolfram.com/RecursiveFunction.html 2. Primitive recursive -- ie any function that is defined using - constant - successor - projection - composition - primitive recursion [This definition is recursive in a bad sense but let that be... The first use of the term is for the set of functions such that... The second is for a specific operation. Comes to the third use: 3. The *operation* of primitive recursion is exactly what programmers call recursion. In other words one specific and characteristic operation is used to give the name to the set being defined. What you're failing to explain is why you would consider that function to be recursive from a programming standpoint. As for putting + under the format of primitive recursion, it would go something like this (I guess) Matching up that definition Put h is what is being defined ie + (or plus) k = 1 f = id g(y, ic, x) = S(ic) #ignore y and x, ic is internal (recursive) call Gives plus(0, x) = x plus((S y), x) = S(plus(y, x)) -- http://mail.python.org/mailman/listinfo/python-list
Re: Faster Recursive Fibonacci Numbers
On May 18, 7:27 pm, RJB rbott...@csusb.edu wrote: Thank you! Very cool and clear. I hoped that there was something that Python made natural I couldn't see after 50 years in other languages. I'd like to work on combining both approaches. It may take a while... From the Knuth identity F[n+m] = .. you pulled out two special cases F[2n+1] = .. and F[2n] = .. If you get one more: F[2n -1] = .. you are done -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Wed, May 18, 2011 at 9:15 AM, rusi rustompm...@gmail.com wrote: What you're failing to explain is why you would consider that function to be recursive from a programming standpoint. As for putting + under the format of primitive recursion, it would go something like this (I guess) Matching up that definition Put h is what is being defined ie + (or plus) k = 1 f = id g(y, ic, x) = S(ic) #ignore y and x, ic is internal (recursive) call Gives plus(0, x) = x plus((S y), x) = S(plus(y, x)) You're still arguing mathematics. I am not disputing that the addition function is primitive recursive (in fact, I asserted that in my original reply). What I am saying is that this *implementation* of the addition function: def add(x, y): return y if x == 0 else add(x-1, y) + 1 is recursive in the programming sense (i.e. it uses the programming technique of recursion), while this implementation is not: def add(x, y): return x + y -- http://mail.python.org/mailman/listinfo/python-list
Python-URL! - weekly Python news and links (May 18)
QOTW: When did we come to the idea that people should be able to program in a language without actually learning it? The fact that Python comes so close to that possibility is nothing short of revolutionary. I suppose one day a reasoning android will be able to sit down at the terminal of a star ship computer and ask simple questions while making random hand movements across a screen, but for now I am afraid that programmers still have to learn programming. - D'Arcy J.M. Cain - 2011-05-11 http://permalink.gmane.org/gmane.comp.python.general/690140 Fast way to convert a set into a list: http://groups.google.com/group/comp.lang.python/t/a3c72619c1e867e3/ 'Still time to submit a proposal to PyCon India 2011: http://pycon.blogspot.com/2011/05/pycon-india-2011-call-for-proposals.html How to make sure equal objects are unique: http://groups.google.com/group/comp.lang.python/t/a8889b7a327756dd/ generator.send() explained: http://groups.google.com/group/comp.lang.python/t/953c8f1f8a5f73ed/ object of different types never compare equal, a documentation bug: http://groups.google.com/group/comp.lang.python/t/6ceb3a40dc263f25/ Ofuscating code: not a good idea http://groups.google.com/group/comp.lang.python/t/f887168ca476618f/ Summer pyGames Registration opens: http://pyfound.blogspot.com/2011/05/summer-pygames-registration-open.html The proper way to handle errors: http://groups.google.com/group/comp.lang.python/t/9c6a47de6bf8b352/ http://groups.google.com/group/comp.lang.python/t/79c38e653587d4a/ A long thread, now discussing an O(log n) algorithm for computing the Fibonacci sequence: http://groups.google.com/group/comp.lang.python/t/b713b14e3e0d9872/e9e64fa9a0348ad8?lnk=gst#e9e64fa9a0348ad8 Implementing a multi-dimensional array: a short but insightful response from Robert Kern: http://groups.google.com/group/comp.lang.python/t/f20a6522369d2bbe/ SciPy 2011, Austin, Texas, 11-16 July 2011: http://conference.scipy.org/scipy2011/index.php Unicode for dummies :-) : http://groups.google.com/group/comp.lang.python/t/23d8592a9170e26e/ Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html Just beginning with Python? This page is a great place to start: http://wiki.python.org/moin/BeginnersGuide/Programmers Planet Python: you want to visit there: http://planet.python.org But don't confuse it with Planet SciPy: http://planet.scipy.org And don't confuse *that* with SciPyTip, a high-quality daily (!) tip for the numerically-inclined: http://twitter.com/SciPyTip Python Insider is the official blog of the Python core development team: http://pyfound.blogspot.com/2011/03/python-dev-launches-python-insider-blog.html The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donations/ Keep up with the PSF at Python Software Foundation News: http://pyfound.blogspot.com The Python Papers aims to publish the efforts of Python enthusiasts: http://pythonpapers.org/ Doug Hellman's Module of the week is essential reading: http://www.doughellmann.com/PyMOTW/ comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/group/comp.lang.python.announce/topics Python411 indexes podcasts ... to help people learn Python ... Updates appear more-than-weekly: http://www.awaretek.com/python/index.html The Python Package Index catalogues packages. http://www.python.org/pypi/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Summary of Python Tracker Issues is an automatically generated report summarizing new bugs, closed ones, and patch submissions. http://search.gmane.org/?author=status%40bugs.python.orggroup=gmane.comp.python.develsort=date nullege is an interesting search Web application, with the intelligence to distinguish between Python code and comments. It provides what appear to be relevant results, and demands neither Java
Re: Python 3.x and bytes
Ian Kelly wrote: On Tue, May 17, 2011 at 2:20 PM, Ethan Furman et...@stoneleaf.us wrote: The big question, though, is would you do it this way: some_var = bytes(23).replace(b'\x00', b'a') or this way? some_var = bytes(b'a' * 23) Actually, I would just do it this way: some_var = b'a' * 23 That's already a bytes object. Passing it into the constructor is redundant. However, as I just discovered, it works well when dealing with a bytearray object: some_var = bytearray(b' ' * size) # want space initialized, not null ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun h...@schaathun.net wrote: On Mon, 16 May 2011 23:42:40 +0100, Rhodri James rho...@wildebst.demon.co.uk wrote: : ...which is, of course, not exactly secure either. A sufficiently : determined hacker won't have much trouble disassembling a shared library : even if you do strip out all the debug information. By chance I'm having : to do something closely related to this at work just at the moment; it's : hard, but far from impossible. But then, nothing is secure in any absolute sense. If you're talking security and not philosophy, there is such a thing as a secure system. As a developer you should aim for it. The best you can do with all your security efforts is to manage risk. Since obfuscation increases the cost of mounting an attack, it also reduces risk, and thereby provides some level of security. The on-the-ground reality is that it doesn't. Lack of access to the source code has not kept windows or adobe acrobat or flash player secure, and they have large full-time security teams, and as you might imagine from the amount of malware floating around targeting those systems there are a lot of people who have these skills in spades. Obviously, if your threat sources are dedicated hackers or maybe MI5, there is no point bothering with obfuscation, but if your threat source is script kiddies, then it might be quite effective. On the theory that any attack model without an adversary is automatically secure? Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Thu, May 19, 2011 at 2:54 AM, geremy condra debat...@gmail.com wrote: On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun h...@schaathun.net wrote: But then, nothing is secure in any absolute sense. If you're talking security and not philosophy, there is such a thing as a secure system. As a developer you should aim for it. Agreed. Things can be secure if you accept caveats. A good server might be secure as long as attackers cannot, say: * Get physical access to the server, remove the hard disk, and tamper with it * Hold a gun to the developer and say Log me in as root or you die * Trigger a burst of cosmic rays that toggle some bits in memory If someone can do that, there's really not much you can do to stop them. But you CAN make a system 100% secure against network-based attacks. Denial of service attacks are the hardest to truly defend against, and if your level of business is low enough, you can probably ignore them in your code, and deal with them by human (Hmm, we seem to be getting ridiculous amounts of traffic from XX.YY.ZZ.*, I think I'll put a temporary ban on that /24). Although some really nasty DOSes can be blocked fairly easily, so it's worth thinking about them. But mainly: Don't panic about the really really obscure attack possibilities, the ones that would only happen if someone with a lot of resources is trying to bring you down. Just deal with the obvious stuff - make sure your server cannot be compromised via a standard network connection. Test your server by connecting with a basic TELNET client (or a hacked-up client, if it uses a binary protocol). Test your client by connecting it to a hacked-up server. Make sure you can't muck up either of them. Assume that any attacker will know every detail about your comms protocol, because chances are he will know most of it. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, 18 May 2011 09:54:30 -0700, geremy condra debat...@gmail.com wrote: : On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun h...@schaathun.net wrote: : But then, nothing is secure in any absolute sense. : : If you're talking security and not philosophy, there is such a thing : as a secure system. As a developer you should aim for it. You think so? Please name one, and let us know how you know that it is secure. : and thereby provides some level of security. : : The on-the-ground reality is that it doesn't. Lack of access to the : source code has not kept windows or adobe acrobat or flash player : secure, and they have large full-time security teams, and as you might : imagine from the amount of malware floating around targeting those : systems there are a lot of people who have these skills in spades. You are just demonstrating that it does not provide complete security, something which I never argued against. : Obviously, if your threat sources are dedicated hackers or maybe MI5, : there is no point bothering with obfuscation, but if your threat source : is script kiddies, then it might be quite effective. : : On the theory that any attack model without an adversary is : automatically secure? No, on the assumption that we were discussing real systems, real threats, and practical solutions, rather than models and theory. There will always be adversaries, but they have limited means, and limited interest in your system. And the limits vary. Any marginal control will stave off a few potential attackers who just could not be bothered. In theory, you can of course talk about absolute security. For instance, one can design something like AES¹, which is secure in a very limited, theoretical model. However, to be of any practical use, AES must be built into a system, interacting with other systems, and the theory and skills to prove that such a system be secure simply has not been developed. Why do you think Common Criteria have not yet specified frameworks for the top levels of assurance? ¹ Advanced Encryption Standard -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
Chris Angelico ros...@gmail.com writes: On Thu, May 19, 2011 at 2:54 AM, geremy condra debat...@gmail.com wrote: On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun h...@schaathun.net wrote: But then, nothing is secure in any absolute sense. If you're talking security and not philosophy, there is such a thing as a secure system. As a developer you should aim for it. Agreed. Things can be secure if you accept caveats. A good server might be secure as long as attackers cannot, say: * Get physical access to the server, remove the hard disk, and tamper with it * Hold a gun to the developer and say Log me in as root or you die * Trigger a burst of cosmic rays that toggle some bits in memory You forgot the most important one: * if none of the software running on it has exploitable issues Personally, I think it's best to understand that no server is ever secure and hence one must always be prepared that a breach can happen. -- John Bokma j3b Blog: http://johnbokma.com/Perl Consultancy: http://castleamber.com/ Perl for books:http://johnbokma.com/perl/help-in-exchange-for-books.html -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, May 18, 2011 at 10:24 AM, Chris Angelico ros...@gmail.com wrote: On Thu, May 19, 2011 at 2:54 AM, geremy condra debat...@gmail.com wrote: On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun h...@schaathun.net wrote: But then, nothing is secure in any absolute sense. If you're talking security and not philosophy, there is such a thing as a secure system. As a developer you should aim for it. Agreed. Things can be secure if you accept caveats. A good server might be secure as long as attackers cannot, say: * Get physical access to the server, remove the hard disk, and tamper with it * Hold a gun to the developer and say Log me in as root or you die * Trigger a burst of cosmic rays that toggle some bits in memory Just a note: you can do many cool things to prevent the last from working, assuming you're talking about RSA fault injection attacks. If someone can do that, there's really not much you can do to stop them. But you CAN make a system 100% secure against network-based attacks. Denial of service attacks are the hardest to truly defend against, and if your level of business is low enough, you can probably ignore them in your code, and deal with them by human (Hmm, we seem to be getting ridiculous amounts of traffic from XX.YY.ZZ.*, I think I'll put a temporary ban on that /24). Although some really nasty DOSes can be blocked fairly easily, so it's worth thinking about them. But mainly: Don't panic about the really really obscure attack possibilities, the ones that would only happen if someone with a lot of resources is trying to bring you down. Just deal with the obvious stuff - make sure your server cannot be compromised via a standard network connection. Just one caveat I would add to this: make sure you're drawing this line at the correct place. If your attack model is wrong things have a tendency to drop from 'impossible' to 'laughably easy' in a hurry. Test your server by connecting with a basic TELNET client (or a hacked-up client, if it uses a binary protocol). Test your client by connecting it to a hacked-up server. Make sure you can't muck up either of them. Assume that any attacker will know every detail about your comms protocol, because chances are he will know most of it. I actually like to use scapy a lot. It's a little slow, but you can really get down deep and still feel sort of sane afterwards, and it makes it easier on you if you don't need to go all the way to the metal. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Thu, May 19, 2011 at 3:31 AM, John Bokma j...@castleamber.com wrote: Agreed. Things can be secure if you accept caveats. A good server might be secure as long as attackers cannot, say: * Get physical access to the server, remove the hard disk, and tamper with it * Hold a gun to the developer and say Log me in as root or you die * Trigger a burst of cosmic rays that toggle some bits in memory You forgot the most important one: * if none of the software running on it has exploitable issues That's not a caveat. That's a purposeful and deliberate goal. And far from impossible. Personally, I think it's best to understand that no server is ever secure and hence one must always be prepared that a breach can happen. You need to balance the risk of a breach against the effort it'd take to prevent. See my comments re DOS attacks; it's not generally worth being preemptive with those, unless you're at a way higher transaction level than this discussion is about (for those who came in late, it's a basic network game, and not Google Docs or the DNS root servers or something). If it's going to impose 500ms latency on all packets just to prevent the one chance in 1E50 that you get some particular attack, then it's really not worthwhile. However, it IS possible to ensure that the server doesn't, for instance, trust the client; those extremely basic protections are well worth the effort (even if it seems like a lot of effort). Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Hans Georg Schaathun h...@schaathun.net writes: [Followup-To: header set to comp.lang.python.] On 17 May 2011 23:42:20 -0700, Thomas A. Russ t...@sevak.isi.edu wrote: : Tree walks are the canonical example of what can't be done in an : iterative fashion without the addition of an explicitly managed stack Of course you can do it. It isn't nice, but it is possible. I assume that you refer to depth first walks, as breadth first is more easily described by iteration on a queue in the first place. Depth first can be achieved by looping over the nodes, with a state keeping references to the current and the previous node considered. Well, unless you have a tree with backpointers, you have to keep the entire parent chain of nodes visited. Otherwise, you won't be able to find the parent node when you need to backtrack. A standard tree representation has only directional links. Consider: A--+---B+---D || |+---E || |+---F | +---C If all you keep is the current and previous node, then the only thing you have reference do when doing the depth-first traverse is: 1. Current = A, Previous = null 2. Current = B. Previous = A 3. Current = D Previous = B 4. Current = E Previous = D 5. now what? You can't get from E or D back to B. By comparing the previous node (pointer or ID) to the current node's parent and children one will know wherefrom the current node was entered, and can choose the next child in the list as the next node, or the parent if all children have been visited. A visit action may be added in any or all times the node is visited. This node requires no stack. The only state space is constant, regardless of the size of the tree, requiring just the two pointers to previous and current. This will only work if there is a backpointer to the parent. So you have to add one extra pointer for each node back to its parent. This extra pointer will be the size of the graph, rather than (on average) log of the size of the graph stack frames. -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Harrison Hill harrish...@gmx.com wrote: No need - I have the Dictionary definition of recursion here: Recursion: (N). See recursion. If you tell a joke, you have to tell it right. Recursion: (N). See recursion. See also tail recursion. Victor. -- Victor Eijkhout -- eijkhout at tacc utexas edu -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Thu, May 19, 2011 at 3:40 AM, geremy condra debat...@gmail.com wrote: Just a note: you can do many cool things to prevent the last from working, assuming you're talking about RSA fault injection attacks. Sure. Each of those caveats can be modified in various ways; keeping checksums of everything in memory, encrypting stored data with something that isn't stored on that computer, etc, etc, etc. But in terms of effort for gain, it's not usually worth it. However, it is a good idea to be aware of your caveats; for instance, are you aware that most Linux systems will allow a root login from another file system (eg a live-boot CD) to access the hard drive read-write, regardless of file ownership and passwords? (My boss wasn't, and was rather surprised at how easily it could be done.) But mainly: Don't panic about the really really obscure attack possibilities... Just one caveat I would add to this: make sure you're drawing this line at the correct place. If your attack model is wrong things have a tendency to drop from 'impossible' to 'laughably easy' in a hurry. Absolutely. Sometimes it's worth scribbling comments in your code like: /* TODO: If someone tries X, it might cause Y. Could rate-limit here if that's an issue. */ Then, you keep an administrative eye on the production code. If you start having problems, you can deal with them fast, rather than having the ridiculous situation of security issues lingering for months or years before finally getting a band-aid solution. Test your server by connecting with a basic TELNET client... I actually like to use scapy a lot. It's a little slow, but you can really get down deep and still feel sort of sane afterwards, and it makes it easier on you if you don't need to go all the way to the metal. Sort of sane? I lost that feeling years ago. :) When I'm working on Windows, I'll sometimes use SMSniff for packet sniffing, but generally, I just stick with high level socket services and depend on the underlying libraries to deal with malformed packets and such. On Linux, I generally whip up a quick script to do whatever job on the spot (Python and Pike are both extremely well suited to this), but on Windows, I use my MUD client, RosMud, which has a passive mode option for playing the part of the server. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On 18 May 2011 09:16:26 -0700, Thomas A. Russ t...@sevak.isi.edu wrote: : Well, unless you have a tree with backpointers, you have to keep the : entire parent chain of nodes visited. Otherwise, you won't be able to : find the parent node when you need to backtrack. A standard tree : representation has only directional links. The array representation of a binary tree is standard, and the «back» (parent) pointers are mathematically given. /Some/ standard tree representation do not have parent pointers. You are right that I assumed parent pointers of some description; but it does demonstrate that tree walks can be done iteratively, without keeping a stack of any sort. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Thu, May 19, 2011 at 2:16 AM, Thomas A. Russ t...@sevak.isi.edu wrote: Well, unless you have a tree with backpointers, you have to keep the entire parent chain of nodes visited. Otherwise, you won't be able to find the parent node when you need to backtrack. A standard tree representation has only directional links. Sure, but there are plenty of trees that do have parent pointers. Widgets on every system I've tinkered with always have, and in a directory structure that doesn't allow files to be in multiple places, it's not hard (look at the . and .. entries in a directory). Of course, file systems are not idealized tree structures, so things will be a bit more complicated. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Hans Georg Schaathun h...@schaathun.net writes: [Followup-To: header set to comp.lang.python.] On 18 May 2011 09:16:26 -0700, Thomas A. Russ t...@sevak.isi.edu wrote: : Well, unless you have a tree with backpointers, you have to keep the : entire parent chain of nodes visited. Otherwise, you won't be able to : find the parent node when you need to backtrack. A standard tree : representation has only directional links. The array representation of a binary tree is standard, and the «back» (parent) pointers are mathematically given. /Some/ standard tree representation do not have parent pointers. I don't think anybody mentioned *binary* trees. The context was directory traversal, in which case you would have nodes with an arbitrary (almost) number of children. You are right that I assumed parent pointers of some description; but it does demonstrate that tree walks can be done iteratively, without keeping a stack of any sort. Except that the chain of parent pointers *would* constitue a stack. -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
might be secure as long as attackers cannot, say: You forgot UFOs. Anyway, again, thanks to everyone for the advice, this is good reading. Incidentally, I don't know to much about security. I know about rate limiting and dos attacks, as well as some others, but I think there's a lot more that I don't know--can someone kind of aim me in the right direction for some of this? I want to be able to take techniques, break my server and then fix it so that can't be done before I head to public with this. -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, May 18, 2011 at 20:24, Chris Angelico ros...@gmail.com wrote: But you CAN make a system 100% secure against network-based attacks. Only by unplugging the network cable. This is called an air gap, and is common in military installations. Anything with a cable plugged in is hackable. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, May 18, 2011 at 20:24, Chris Angelico ros...@gmail.com wrote: Denial of service attacks are the hardest to truly defend against, and if your level of business is low enough, you can probably ignore them in your code, and deal with them by human (Hmm, we seem to be getting ridiculous amounts of traffic from XX.YY.ZZ.*, I think I'll put a temporary ban on that /24). Although some really nasty DOSes can be blocked fairly easily, so it's worth thinking about them. The python code should not be concerned with DDoS, that is what iptables is for. Remember, never do in code what Linux will do for you. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Thu, May 19, 2011 at 4:31 AM, Dotan Cohen dotanco...@gmail.com wrote: The python code should not be concerned with DDoS, that is what iptables is for. Remember, never do in code what Linux will do for you. In general, yes. Denial of service is a fairly broad term, though, and if there's a computationally-expensive request that a client can send, then it may be worth rate-limiting it. Or if there's a request that causes your server to send out inordinate amounts of data, and you're running it on a typical home internet connection, then that's a DOS vector too. So it's not only an iptables issue. But yes. The system is the entire system, not just the Python code you're writing. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On Wed, 18 May 2011 20:20:01 +0200, Raymond Wiker raw@RAWMBP-2.local wrote: : I don't think anybody mentioned *binary* trees. The context was : directory traversal, in which case you would have nodes with an : arbitrary (almost) number of children. If we are being specific, then directory trees do have parent pointers. My point was really that «standard tree representations» is not a well-defined concept, and having parent pointers is as standard as not having them. : Except that the chain of parent pointers *would* constitue a : stack. In the sense that the tree itself is a stack, yes. But if we consider the tree (or one of its branches) to be a stack, then the original claim becomes a tautology. But you do have a point. Keeping a stack of nodes on the path back to root is a great deal simpler and cheaper than a call stack, and not really a significant expense in context. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Thu, May 19, 2011 at 4:20 AM, Raymond Wiker raw@rawmbp-2.local wrote: You are right that I assumed parent pointers of some description; but it does demonstrate that tree walks can be done iteratively, without keeping a stack of any sort. Except that the chain of parent pointers *would* constitue a stack. Howso? It's part of your data structure, not part of your algorithm; and it's not something that grows and shrinks as you traverse. These considerations may be crucial if, for instance, you want to walk your tree in a signal handler, and you don't know how much memory is available to you... Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Thu, May 19, 2011 at 4:26 AM, Littlefield, Tyler ty...@tysdomain.com wrote: might be secure as long as attackers cannot, say: You forgot UFOs. Anyway, again, thanks to everyone for the advice, this is good reading. Incidentally, I don't know to much about security. I know about rate limiting and dos attacks, as well as some others, but I think there's a lot more that I don't know--can someone kind of aim me in the right direction for some of this? I want to be able to take techniques, break my server and then fix it so that can't be done before I head to public with this. Your last sentence IS the right direction. The two easiest ways to find out if your system is secure are (1) try to break it, and (2) pore over the code and see what can be broken. When you start testing things, try doing things in the wrong order. Your server should either cope with it fine, or throw back an error to that client, but should never allow any action that that client hasn't already proven he's allowed to do. There's plenty of people here who know what they're talking about when it comes to security (just skim over this thread for a few good names!), so if you have specific questions regarding your Python code, do ask. Alternatively, if it's not particularly Python-related, I would be happy for you to email me privately; I'm a gamer, and run an online game, so I'd be quite willing to have a bit of a poke at your code. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
t...@sevak.isi.edu (Thomas A. Russ) writes:
Well, unless you have a tree with backpointers, you have to keep the
entire parent chain of nodes visited. Otherwise, you won't be able to
find the parent node when you need to backtrack. A standard tree
representation has only directional links.
Consider:
A--+---B+---D
||
|+---E
||
|+---F
|
+---C
If all you keep is the current and previous node, then the only thing
you have reference do when doing the depth-first traverse is:
1. Current = A, Previous = null
2. Current = B. Previous = A
3. Current = D Previous = B
4. Current = E Previous = D
5. now what? You can't get from E or D back to B.
By comparing the previous node (pointer or ID) to the
current node's parent and children one will know wherefrom the
current node was entered, and can choose the next child in the
list as the next node, or the parent if all children have been
visited. A visit action may be added in any or all times the
node is visited.
This node requires no stack. The only state space is constant,
regardless of the size of the tree, requiring just the two pointers
to previous and current.
This will only work if there is a backpointer to the parent.
No, you don't need backpointers; some cases have been mentionned in the
other answer, but in general:
(defun parent (tree node)
(if (member node (children tree))
tree
(some (lambda (child) (parent child node)) (children tree
Yes, the question wasn't about time complexity.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, May 18, 2011 at 10:33 AM, Hans Georg Schaathun h...@schaathun.net wrote: On Wed, 18 May 2011 09:54:30 -0700, geremy condra debat...@gmail.com wrote: : On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun h...@schaathun.net wrote: : But then, nothing is secure in any absolute sense. : : If you're talking security and not philosophy, there is such a thing : as a secure system. As a developer you should aim for it. You think so? Please name one, and let us know how you know that it is secure. I was playing around with an HSM the other day that had originally targeted FIPS 140-3 level 5, complete with formal verification models and active side-channel countermeasures. I'm quite confident that it was secure in nearly any practical sense. : and thereby provides some level of security. : : The on-the-ground reality is that it doesn't. Lack of access to the : source code has not kept windows or adobe acrobat or flash player : secure, and they have large full-time security teams, and as you might : imagine from the amount of malware floating around targeting those : systems there are a lot of people who have these skills in spades. You are just demonstrating that it does not provide complete security, something which I never argued against. Ah, my mistake- when you said 'some level of security' I read that as 'some meaningful level of security'. If you were arguing that it provided roughly as much protection to your code as the curtain of air surrounding you does to your body, then yes- you're correct. : Obviously, if your threat sources are dedicated hackers or maybe MI5, : there is no point bothering with obfuscation, but if your threat source : is script kiddies, then it might be quite effective. : : On the theory that any attack model without an adversary is : automatically secure? No, on the assumption that we were discussing real systems, real threats, and practical solutions, rather than models and theory. There will always be adversaries, but they have limited means, and limited interest in your system. And the limits vary. Any marginal control will stave off a few potential attackers who just could not be bothered. Empirically this doesn't appear to be a successful gambit, and from an attacker's point of view it's pretty easy to see why. When a system I'm trying to break turns out to have done something stupid like this, it really just ticks me off, and I know a lot of actual attackers who think the same way. In theory, you can of course talk about absolute security. For instance, one can design something like AES¹, which is secure in a very limited, theoretical model. However, to be of any practical use, AES must be built into a system, interacting with other systems, and the theory and skills to prove that such a system be secure simply has not been developed. This is flatly incorrect. Why do you think Common Criteria have not yet specified frameworks for the top levels of assurance? Perhaps because the lower levels of 'assurance' don't seem to provide very much. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Hans Georg Schaathun h...@schaathun.net writes: [Followup-To: header set to comp.lang.python.] On Wed, 18 May 2011 20:20:01 +0200, Raymond Wiker raw@RAWMBP-2.local wrote: : I don't think anybody mentioned *binary* trees. The context was : directory traversal, in which case you would have nodes with an : arbitrary (almost) number of children. If we are being specific, then directory trees do have parent pointers. My point was really that «standard tree representations» is not a well-defined concept, and having parent pointers is as standard as not having them. I cannot see that going back to the original case (directory traversal) is any more specific than talking about a completely unrelated case (binary trees). Further, even though most(?) hierarchical file systems have parent pointers, this is not necessary. : Except that the chain of parent pointers *would* constitue a : stack. In the sense that the tree itself is a stack, yes. But if we consider the tree (or one of its branches) to be a stack, then the original claim becomes a tautology. No, the tree is not a stack, but the chain of parent pointers from a particular node may be considered as a stack that records the path taken to reach the current node. But you do have a point. Keeping a stack of nodes on the path back to root is a great deal simpler and cheaper than a call stack, and not really a significant expense in context. For this particular operation, possibly. For other tree operations, a single parent pointer may not be sufficient. -- http://mail.python.org/mailman/listinfo/python-list
Re: python logging
On 18/05/11 03:09, Fei wrote: On May 17, 6:55 pm, Ian Kellyian.g.ke...@gmail.com wrote: On Tue, May 17, 2011 at 2:55 PM, Feimail2...@gmail.com wrote: where is default logging file on Mac? I saw lots of app just import logging, and begins to logging.info(...) etc. I'm not sure where to look at the logging configuration to figure out the log location. There is no default log file. You're seeing that because logging only needs to be configured by the program once, not on a per-module basis. Thus most modules will just do import logging on the assumption that the configuration has already been performed somewhere else. If no logging configuration is done at all, then the logging statements will have no effect. Thanks Ian. That's not exactly how it works. You can use logging without any configuration and the default output will be console. In addition default logging level is warning, so: logging.info(Some text) won't show anything and logging.warning(Other text) will show: WARNING:root:Other text Please check the link I gave before. Bye -- http://mail.python.org/mailman/listinfo/python-list
Re: How To Make Fast Money Legally
On Wed, 18 May 2011 12:06:07 -0700 (PDT) tmac641...@yahoo.com tmac641...@yahoo.com wrote: HOW TO MAKE EASY MONEY FAST AND LEGALLY Wow! Was this stuck in someone's mail queue since 1992? -- D'Arcy J.M. Cain da...@druid.net | 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: obviscating python code for distribution
On Wed, 18 May 2011 12:07:49 -0700, geremy condra debat...@gmail.com wrote: : I was playing around with an HSM the other day that had originally : targeted FIPS 140-3 level 5, complete with formal verification models : and active side-channel countermeasures. I'm quite confident that it : was secure in nearly any practical sense. And you ostensibly use the word /nearly/ rather than «absolutely». It seems that we agree. BTW, according to the sources I can find quickly, FIPS 140-3 targets /modules/ and not systems. : Ah, my mistake- when you said 'some level of security' I read that as : 'some meaningful level of security'. If you were arguing that it : provided roughly as much protection to your code as the curtain of air : surrounding you does to your body, then yes- you're correct. Well, I didn't. Whether it is meaningful is relative and dependent on the context, but it sure isn't meaningful if any values at stake are. : Empirically this doesn't appear to be a successful gambit, and from an : attacker's point of view it's pretty easy to see why. When a system : I'm trying to break turns out to have done something stupid like this, : it really just ticks me off, and I know a lot of actual attackers who : think the same way. That is very true. It is a very crude measure with a marginal effect on risk. Going out of one's way to try to obfuscate the code as machine code, as was the starting point of the discussion, is surely not a good strategy, as one is then spending significant time to achieve a rather insignificant. My main concern is that the use of absolutes, «you need this», and «that is silly», is drawing attention from the main point. Rather, get to know your risks and focus on the greater ones. Consider possible controls, and choose cheap and effective ones. Even a marginally effective control may be worth-while if the cost is even less. We all seem to agree on the main point; many have argued the same way. As an aside, OTOH, don't you think MAYFARE would have been broken earlier if the source code were open? It was around for ages before it was. : In theory, you can of course talk about absolute security. For : instance, one can design something like AES¹, which is secure in : a very limited, theoretical model. However, to be of any practical : use, AES must be built into a system, interacting with other systems, : and the theory and skills to prove that such a system be secure simply : has not been developed. : : This is flatly incorrect. Which part of it? If you claim that the theory and skills to prove it exist, could you give a reference please? Of course, if you are only thinking of «nearly any practical sense» again, then we agree and always did. : Why do you think Common Criteria have not yet specified frameworks : for the top levels of assurance? : : Perhaps because the lower levels of 'assurance' don't seem to provide very much. If the lower levels do not, would that not be an argument to implement more levels? Too many governments have put too much resources into this to just throw it away if the methodology to achieve higher assurance could be codified. Or maybe it is right to say that the theory and skills do exist, but the money to gather it all in one project to demonstrate the security of a single system does not :-) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On Wed, 18 May 2011 21:09:15 +0200, Raymond Wiker raw@RAWMBP-2.local wrote: : In the sense that the tree itself is a stack, yes. But if we : consider the tree (or one of its branches) to be a stack, then : the original claim becomes a tautology. : : No, the tree is not a stack, but the chain of parent pointers : from a particular node may be considered as a stack that records the : path taken to reach the current node. That is one of its branches, yes, path from root towards leaf. It is part of the data structure, and you don't travers a data structure without using the datastructure. : But you do have a point. Keeping a stack of nodes on the path : back to root is a great deal simpler and cheaper than a call : stack, and not really a significant expense in context. : : For this particular operation, possibly. For other tree : operations, a single parent pointer may not be sufficient. Que? What tree operations do you have in mind? We have covered all the standard textbook tree walks by now. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On 5/17/2011 3:26 PM, Xah Lee wrote: might be of interest. 〈English Idiom in Unix: Directory Recursively〉 http://xahlee.org/comp/idiom_directory_recursively.html -- English Idiom in Unix: Directory Recursively Xah Lee, 2011-05-17 Today, let's discuss something in the category of lingustics. You know how in unix tools, when you want to delete the whole directory and all sub-directories and files in it, it's referred as “recursive”? The proper terminology is subtree, subfolder, or subdirectory. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Hans Georg Schaathun écrivit: : also, in the rsync case: “This would recursively transfer all files : from the directory … ”, what does the word “recursively” mean there? Exactly the same as it does in «listing the directory recursively» or «deleting the directory recursively». Traversing recursively a directory is more readily understandable when there are sub-directories, the operation involves going down those sub-directories and applying the same function ad infinitum. Excuse my Latin. Again the distinction could be useful. A non-recursive «rsync dir1 dir2» probably isn't useful, but «rsync * dir2» might be. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Hans Georg Schaathun h...@schaathun.net writes: [Followup-To: header set to comp.lang.python.] On Wed, 18 May 2011 21:09:15 +0200, Raymond Wiker raw@RAWMBP-2.local wrote: : In the sense that the tree itself is a stack, yes. But if we : consider the tree (or one of its branches) to be a stack, then : the original claim becomes a tautology. : : No, the tree is not a stack, but the chain of parent pointers : from a particular node may be considered as a stack that records the : path taken to reach the current node. That is one of its branches, yes, path from root towards leaf. It is part of the data structure, and you don't travers a data structure without using the datastructure. : But you do have a point. Keeping a stack of nodes on the path : back to root is a great deal simpler and cheaper than a call : stack, and not really a significant expense in context. : : For this particular operation, possibly. For other tree : operations, a single parent pointer may not be sufficient. Que? What tree operations do you have in mind? We have covered all the standard textbook tree walks by now. I said tree operations, not tree walks. A tree operation might involve several tree walks. Further, there has been an implicit assumption (I think) in this discussion that the order of children is given, or does not matter - if this is not the case, then you also need to maintain a stack of data structures representing lists (or sets) of children. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On 05/18/2011 02:50 AM, Harrison Hill wrote: Recursion: (N). See recursion. The index of IBM's Document Composition Facility SCRIPT/VS Text Programmer's Guide, Release 3.0 (form SH35-0069-2), put it thus: Circular definition See definition, circular definition circular 211 See also circular definition Sadly, only the Release 4 manuals are available online anymore. ¬R -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Xah Lee xah...@gmail.com: In the emacs case: “Recursive delete of xx? (y or n) ”, what could it possibly mean by the word “recursive” there? Like, it might delete the directory but not delete all files in it? My understanding is that non-recursive means, I think there are no (non- empty?) subdirectories, or I haven't given the matter any thought, so if there are any such subdirectories, tell me and don't do anything. Recursive means I want everything deleted regardless. BICBW. -- Mike Barnes Cheshire, England -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On 17/05/2011 23:20, Ian Kelly wrote: On Tue, May 17, 2011 at 4:26 PM, Xah Leexah...@gmail.com wrote: Though, if you think about it, it's not exactly a correct description. “Recursive”, or “recursion”, refers to a particular type of algorithm, or a implementation using that algorithm. Only when used as programming jargon. In mathematics, recursive function does *not* mean a function implemented using a recursive algorithm. It's just a formal definition of a specific class of mathematical functions. As it turns out, recursive also has a non-technical definition, which again has nothing to do with algorithms except in the broadest sense: recursiveadj. 1. pertaining to or using a rule or procedure that can be applied repeatedly (from dictionary.com) This definition fits the Unix usage perfectly. I concur, although my dictionary defines the base of the word: to happen many times or to happen again http://dictionary.cambridge.org/dictionary/british/recur#recur__3 Perhaps the gp of the post might profit from a more holistic approach when adopting an opinion or at least consult a dictionary before going into a rant. -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: python logging
2011/5/18 Rafael Durán Castañeda rafadurancastan...@gmail.com: That's not exactly how it works. You can use logging without any configuration and the default output will be console. In addition default logging level is warning, so: logging.info(Some text) won't show anything and logging.warning(Other text) will show: WARNING:root:Other text Please check the link I gave before. Bye Odd. That seems to work, but it contradicts the documentation at: http://docs.python.org/howto/logging.html#what-happens-if-no-configuration-is-provided -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, May 18, 2011 at 12:56 PM, Hans Georg Schaathun h...@schaathun.net wrote: On Wed, 18 May 2011 12:07:49 -0700, geremy condra debat...@gmail.com wrote: : I was playing around with an HSM the other day that had originally : targeted FIPS 140-3 level 5, complete with formal verification models : and active side-channel countermeasures. I'm quite confident that it : was secure in nearly any practical sense. And you ostensibly use the word /nearly/ rather than «absolutely». It seems that we agree. Systems can be designed that are absolutely secure under reasonable assumptions. The fact that it has assumptions does not make your statement true. BTW, according to the sources I can find quickly, FIPS 140-3 targets /modules/ and not systems. I can't tell if you're trying to play word games with the distinction between system and module or if you're just saying that you aren't sure what FIPS actually certifies. Could you please clarify? : Ah, my mistake- when you said 'some level of security' I read that as : 'some meaningful level of security'. If you were arguing that it : provided roughly as much protection to your code as the curtain of air : surrounding you does to your body, then yes- you're correct. Well, I didn't. Whether it is meaningful is relative and dependent on the context, but it sure isn't meaningful if any values at stake are. Again, I'm unsure what you're going for here. It sounds like you're saying that obfuscation doesn't provide meaningful security, which is my point. : Empirically this doesn't appear to be a successful gambit, and from an : attacker's point of view it's pretty easy to see why. When a system : I'm trying to break turns out to have done something stupid like this, : it really just ticks me off, and I know a lot of actual attackers who : think the same way. That is very true. It is a very crude measure with a marginal effect on risk. Going out of one's way to try to obfuscate the code as machine code, as was the starting point of the discussion, is surely not a good strategy, as one is then spending significant time to achieve a rather insignificant. My main concern is that the use of absolutes, «you need this», and «that is silly», is drawing attention from the main point. Rather, get to know your risks and focus on the greater ones. Consider possible controls, and choose cheap and effective ones. Even a marginally effective control may be worth-while if the cost is even less. We all seem to agree on the main point; many have argued the same way. As an aside, OTOH, don't you think MAYFARE would have been broken earlier if the source code were open? It was around for ages before it was. Are you talking about the Mayfair classical cipher here? : In theory, you can of course talk about absolute security. For : instance, one can design something like AES¹, which is secure in : a very limited, theoretical model. However, to be of any practical : use, AES must be built into a system, interacting with other systems, : and the theory and skills to prove that such a system be secure simply : has not been developed. : : This is flatly incorrect. Which part of it? If you claim that the theory and skills to prove it exist, could you give a reference please? The entire field of formal modeling and verification has grown around solving this problem. My new favorite in the field is formal models and techniques for analyzing security protocols, but there are other works discussing OS kernel verification (which has gotten a lot of attention lately) and tons of academic literature. Google (scholar) is the place to go. Of course, if you are only thinking of «nearly any practical sense» again, then we agree and always did. Nope, talking about formal methods. : Why do you think Common Criteria have not yet specified frameworks : for the top levels of assurance? : : Perhaps because the lower levels of 'assurance' don't seem to provide very much. If the lower levels do not, would that not be an argument to implement more levels? Too many governments have put too much resources into this to just throw it away if the methodology to achieve higher assurance could be codified. If you can't say with confidence that something meets minimum security standards, the answer is not to try to say it meets high security standards. Or maybe it is right to say that the theory and skills do exist, but the money to gather it all in one project to demonstrate the security of a single system does not :-) Sorry, but again this is not correct. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, May 18, 2011 at 11:26 AM, Littlefield, Tyler ty...@tysdomain.com wrote: might be secure as long as attackers cannot, say: You forgot UFOs. Anyway, again, thanks to everyone for the advice, this is good reading. Incidentally, I don't know to much about security. I know about rate limiting and dos attacks, as well as some others, but I think there's a lot more that I don't know--can someone kind of aim me in the right direction for some of this? I want to be able to take techniques, break my server and then fix it so that can't be done before I head to public with this. One good thing to do is to just read some of the black hat papers. They're pretty accessible and even if you don't know everything they're saying you should be able to get a general feel for things that way. You might also try working through things like Damn Vulnerable Web App, if you have the time. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: python logging
On 18/05/11 23:29, Ian Kelly wrote: 2011/5/18 Rafael Durán Castañedarafadurancastan...@gmail.com: That's not exactly how it works. You can use logging without any configuration and the default output will be console. In addition default logging level is warning, so: logging.info(Some text) won't show anything and logging.warning(Other text) will show: WARNING:root:Other text Please check the link I gave before. Bye Odd. That seems to work, but it contradicts the documentation at: http://docs.python.org/howto/logging.html#what-happens-if-no-configuration-is-provided I think you are confuse because of you are looking at advanced logging, where getLogger is being used. Simple logging works without any configuration, getLogger doesn't. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On 5/18/2011 5:24 AM, lkcl wrote: There seem to be two somewhat separate requirement issues: the interpreter binary and the language version. a) at the moment a http://python.org 2.N interpreter is required to actually run the translator. if you use http://python.org 2.5 or 2.6 you do not need to use the --internal-ast option. if you use 2.4, 2.7 or above, you will need to use --internal-ast because we're heavily reliant on the internal c-based compile module [without the --internal-ast option enabled]. I presume '--internal-ast' is a 'compile the interpreter' option. Since I have never compilied Python (or anything else for perhaps 15 years), I do not understand completely. Am I correct to guess that the PSF Windows binaries for 2.7 were not compiled with the flag, and will not work? If so, Windows users should, I would think, use the latest 2.6.6 binaries. b) the actual pyjs interpreter grammar (AST) was 2.5 but has mostly been updated to 2.6. actual python syntax / features are therefore mostly 2.5, with someone having pointed out that slice has different return results it's hard to say exactly which is best to be picked, 2.5 or 2.6. nobody's needed slice until recently, so it's not an issue that's ever come up before. If I understand this, the safe thing to do is to stick with 2.5 syntax and omit exotic 3.x features put into 2.6 for eventual porting to 3.x. the thing is - it's worth reiterating: you just... really don't need as much python interoperability for user-interfaces when they're split along MVC lines. bear in mind that it's necessary to do that split: it's web browser technology, you can't *actually* execute things like psycopg or mysql in a web browser as javascript! so once you've divided that application into python that runs the actual user interface and python on the other side of the AJAX barrier e.g. a django app you're left with a far smaller task for the pyjs interpreter to have to tackle. I do not get all this but it seems to say that I do not really need all the features of the later Pythons to write user-interface code. But I am not sure how this applies to business code behind the front end. Of course, it might work to run the UI in a separate process if on the same machine. otherwise please - really: just saying give me support for python 3.x or else is ... And I did not say that. yeah i know - i'm sorry: it just, with a little bit of twisting, could be construed as implying that. Let me be clear: some people think that free (as in beer) software developers have some sort of one-sided responsibility or obligation to users who pay nothing. I don't. If I say Give me a Python 3 version of pyjamas or I will not use it, I consider you free to respond Fine, don't use it. End of story until I compromise or contribute. I feel free to say the same to anyone who says Stop developing new versions of Python or I will quit using the current version. :) i think... people forget that there are now two mutually- exclusively-incompatible programming languages out there, where the first six letters of the name of the programming language happen to be the same... Something of an exaggeration. It might well be possible to use a 3to2 frontend and run a mildly restricted subset of 3.x. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: python logging
2011/5/18 Rafael Durán Castañeda rafadurancastan...@gmail.com:
I think you are confuse because of you are looking at advanced logging,
where getLogger is being used. Simple logging works without any
configuration, getLogger doesn't.
It seems to work without any configuration just as well as the root logger:
import logging
logging.getLogger('foo').warning('test')
WARNING:foo:test
Or am I misunderstanding you?
--
http://mail.python.org/mailman/listinfo/python-list
Re: python logging
On 19/05/11 00:10, Ian Kelly wrote:
2011/5/18 Rafael Durán Castañedarafadurancastan...@gmail.com:
I think you are confuse because of you are looking at advanced logging,
where getLogger is being used. Simple logging works without any
configuration, getLogger doesn't.
It seems to work without any configuration just as well as the root logger:
import logging
logging.getLogger('foo').warning('test')
WARNING:foo:test
Or am I misunderstanding you?
Are you using python 2.x or 3.x? At python 2.7 using:
import logging
logging.getLogger('log').warning('test')
I got:
No handlers could be found for logger log
--
http://mail.python.org/mailman/listinfo/python-list
Re: python logging
On May 18, 11:10 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
It seems to work without any configuration just as well as the root logger:
importlogging
logging.getLogger('foo').warning('test')
WARNING:foo:test
Or am I misunderstanding you?
In general for Python 2.x, the code
import logging
logging.getLogger('foo').warning('test')
will produce
No handlers could be found for logger foo
unless loggers have been configured, e.g. by calling logging.warning()
- that call implicitly adds a console handler to the root logger, if
no other handlers have been configured for the root logger.
In Python 3.2 and later, if no handlers have been configured, messages
at level WARNING and greater will be printed to sys.stderr using a
handler of last resort - see
http://docs.python.org/py3k/howto/logging.html#what-happens-if-no-configuration-is-provided
Regards,
Vinay Sajip
--
http://mail.python.org/mailman/listinfo/python-list
Indexable properties recipe
http://code.activestate.com/recipes/577703-item-properties/ -- http://mail.python.org/mailman/listinfo/python-list
Re: python logging
2011/5/18 Rafael Durán Castañeda rafadurancastan...@gmail.com:
Are you using python 2.x or 3.x? At python 2.7 using:
import logging
logging.getLogger('log').warning('test')
I got:
No handlers could be found for logger log
Ah, that's it. I was using Python 2.5. Using 2.7 I get the same
result that you do.
Still, it's a surprising change that doesn't seem to be documented as
such. I'm not sure whether it's a regression or an intentional
change.
--
http://mail.python.org/mailman/listinfo/python-list
Re: python logging
2011/5/18 Ian Kelly ian.g.ke...@gmail.com:
Ah, that's it. I was using Python 2.5. Using 2.7 I get the same
result that you do.
Still, it's a surprising change that doesn't seem to be documented as
such. I'm not sure whether it's a regression or an intentional
change.
I was wrong, it's more complicated than that.
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.
import logging
logging.getLogger('log').warning('test')
No handlers could be found for logger log
logging.warning('test')
WARNING:root:test
logging.getLogger('log').warning('test')
WARNING:log:test
Apparently, getLogger() is unconfigured by default, but if you just
use the root logger once, then they magically get configured.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How To Make Fast Money Legally
On Wed, 2011-05-18 at 15:48 -0400, D'Arcy J.M. Cain wrote: On Wed, 18 May 2011 12:06:07 -0700 (PDT) tmac641...@yahoo.com tmac641...@yahoo.com wrote: HOW TO MAKE EASY MONEY FAST AND LEGALLY Wow! Was this stuck in someone's mail queue since 1992? Me too! -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand html.parser.HTMLParser
On 2011.05.18 03:30 AM, Stefan Behnel wrote: Well, it pretty clearly states that on the PyPI page, but I also added it to the project home page now. lxml 2.3 works with any CPython version from 2.3 to 3.2. Thank you. I never would've looked at PyPI for info on a project that has its own site. I'll take a look at it. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
rusi wrote: On May 18, 5:09 pm, Peter Moylan inva...@peter.pmoylan.org.invalid wrote: ObAUE: In common parlance, the English word recursion means pretty much the same as what computing people call iteration. This might be the first time I have ever found a point of agreement with Xah Lee. Maybe the common usage mirrors the facts better than the lore that half-baked programmers remain devoted to. Consider first implementations: The implementation of recursion by a typical language (eg gcc for C) maximizes generality at the cost of efficiency The implementation of a very special case -- tail recursion -- in some special languages (most notably scheme) is required to be competitive with the iterative solution. [If I remember right in Chez scheme tail recursion was more efficient than a do (iteration) because a do typically needed assignment and assignment was more expensive than parameter passing] I believe the word legend, or something equivalent, was used elsewhere in this thread in this connection. The supposed inefficiency of recursive implementations is based largely on the properties of hardware that is now obsolete. With modern processors there's no great efficiency hit. In some of the smaller microcontrollers, it's true, you do have to worry about stack overflow; but the ARM processors, for example, provide plenty of stack space. In the microcontroller world, the big performance hits come from the fact that the only available compilers are for C and sometimes C++. (And nobody uses assembly language except for the very little jobs.) The nature of the C language prevents compilers from doing optimisations that are standard in compilers for high-level languages. Most C compilers will, for example, always pass parameters on the stack, despite the generous supply of registers available in newer hardware. -- Peter Moylan, Newcastle, NSW, Australia. http://www.pmoylan.org For an e-mail address, see my web page. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On 5/18/2011 9:42 AM, lkcl wrote: he's got a good point, terry. breaking backwards-compatibility was a completely mad and incomprehensible decision. I see that I should take everything you (or Harris) say with a big grain of salt;-). You just gave me a lecture about the impossibility of doing everything one might like with limited all or mostly volunteer resources. So surely you can comprehend that the same applies to CPython also. Given that Python 1.0/1 had some design defects that became evident with experience and simply lacked some things thought of later, I can think of several options: 1. Never fix them. 2. Add fixes, but keep the old stuff. If the old and new ways are somewhat compatible, keep both available at the same time*. If they conflict, keep old as default and make new available on demand (future import)#. This was 2.x strategy. 2A. Make new ways default and have past imports. 3. Gradually delete old. This was and is policy mostly for library. 4. Delete lots of old ways all at once. This was 3.x. What would you have had us do instead? * Example: old and new style classes. Problems: the differences are hard to learn and hard to remember; they are sometimes irrelevant, but sometimes not; if you import and instantiate a class, you may not know which you have. # Example: int division. Problems: having the deprecated meaning be default is a damn nuisance; learning it is a stupid burden; if you see 'a/b' in a snippet extracted from a file, you do not know what it means. 2.7 is really the end of the road for strategy 2. Keeping obsolete features around is a learning burden for most newbies and a maintenance burden for developers. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
Littlefield, Tyler wrote: I know about rate limiting and dos attacks, as well as some others, but I think there's a lot more that I don't know--can someone kind of aim me in the right direction for some of this? I want to be able to take techniques, break my server and then fix it so that can't be done before I head to public with this. Black-hat and gray-hat papers are some of the best resources; and entertaining ta-boot... Four resources that you will what to look into, in no particular order: Erickson, Jon, Hacking: The Art of Exploitation, 2nd ed, San Francisco: No Starch Press, 2008. Anonymous, Maximum Linux Security: A Hacker's Guide to Protecting Your Linux Server and Workstation, Indianapolis: Sams Publishing, 2000. (check for other editions) (this volume is a good read, even for other platforms, but is geared specifically to Linux) Graves, Kimberly, CEH Certified Ethical Hacker: Study Guide, Indianapolis: Wiley Publishing, 2010. Seitz, Justin, Gray Hat Python: Python Programming for Hackers and Reverse Engineers, San Francisco: No Starch Press, 2009. The best way to protect your system is first to be able to understand how someone else will attempt to compromise it. I personally am an *ethical* hacker; by definition, I exploit possibilities, for problem solving, and I cause *NO* harm. Having said that, I have studied *all* of the techniques employed in the field for causing harm; why? Because that is the *only* way to know how to defend against them. Its like missile anti missile...virus anti virus, and the like. Because *all* of software is mathematical by nature it is not possible to lock software with software... this is partially the decidability problem at work. But mostly its a matter of their skills getting better... yours better be better yet, and when they get even better than you--- well you better be ready to improve ... and on and on it goes... But, first you need to understand what you're up against. There is absolutely *no* way to prevent reverse engineering. Its all just code, and that code can be unraveled with the right math and enough time. (time and talent is all it takes; that and the will to be tenacious and uncompromising. If someone wants your system badly enough, they will own it... its just a matter of time... so be ready for it... like the Bible says, If the master of the house knew what hour the thief would break in and steal, he would have kept better watch on his house! kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: How to select Python web frameworks and which one is the best framework ?
On Tue, May 17, 2011 at 1:20 PM, VGNU Linux vgnuli...@gmail.com wrote: Hi all, I am confused on which web framework to select for developing a small data driven web application. Application will have features generally found in now-a-days web application like security, database connectivity, authentication etc. I found few web frameworks over the net like django, zope 2/3, pylons, turbogears, web2py, grok etc. etc. I just want to know that how developers/managers/organizations select a framework which best suits their needs ? what are the parameters for selection ? also which is the best and widely used web framework for python ? I apologize if this is a repeated question. Regards, VGNU Please guys help as I am novice to web development. Regards, VGNU -- http://mail.python.org/mailman/listinfo/python-list
Re: Needed: Real-world examples for Python's Cooperative Multiple Inheritance
On 5/4/2011 11:36 AM, Ethan Furman wrote: Raymond Hettinger wrote: I'm writing-up more guidance on how to use super() and would like to point at some real-world Python examples of cooperative multiple inheritance. Multiple inheritance in Python is so badly designed that it probably should not be used in production code. Generalizing multiple inheritance from a tree to a directed acyclic graph is usually a mistake. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On Wed, 18 May 2011 22:40:28 +0200, Raymond Wiker raw@RAWMBP-2.local wrote: : I said tree operations, not tree walks. A tree operation might : involve several tree walks. OK. The original claim under dispute regarded tree walks. : Further, there has been an implicit : assumption (I think) in this discussion that the order of children is : given, or does not matter - if this is not the case, then you also need : to maintain a stack of data structures representing lists (or sets) of : children. It assumes that there is some canonical ordering on the children. If the tree nodes store their children as sets, where the implementation does not guarantee that they can be retrieved in the same order every time, then it breaks. However, that would be an unusual implementation. The tree has to store the children for each node, one way or another. The only thing I am assuming is that the children can be inspected in the same order every time the node is visited. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, 18 May 2011 14:34:46 -0700, geremy condra debat...@gmail.com wrote: : Systems can be designed that are absolutely secure under reasonable : assumptions. The fact that it has assumptions does not make your : statement true. : (...) : I can't tell if you're trying to play word games with the distinction : between system and module or if you're just saying that you aren't : sure what FIPS actually certifies. Could you please clarify? The distinction between system and module is rather significant. If you only consider modules, you have bounded your problem and drastically limited the complexity. : Again, I'm unsure what you're going for here. It sounds like you're : saying that obfuscation doesn't provide meaningful security, which is : my point. Meaningful is a relative term, and it is hard to rule out the possibility that meaning can be found in some case. Overall, we agree though. : Are you talking about the Mayfair classical cipher here? I am talking about the system used in public transport cards like Oyster and Octopus. I am not sure how classical it is, or whether mayfair/mayfare referred to the system or just a cipher. Any way, it was broken, and it took years. : The entire field of formal modeling and verification has grown around : solving this problem. My new favorite in the field is formal models : and techniques for analyzing security protocols, but there are other : works discussing OS kernel verification (which has gotten a lot of : attention lately) and tons of academic literature. Google (scholar) is : the place to go. Sure, but now you are considering modules, rather than systems again. It is when these reliable components are put together to form systems that people fail (empirically). : If you can't say with confidence that something meets minimum security : standards, the answer is not to try to say it meets high security : standards. So what? The levels of assurance have nothing to do with standards. The levels of assurance refer to the /confidence/ you can have that the standards are met. : Or maybe it is right to say that the theory and skills do exist, but the : money to gather it all in one project to demonstrate the security of : a single system does not :-) : : Sorry, but again this is not correct. You keep saying that, but whenever you try to back the claim, you keep referring to limited components and not systems at all. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
[issue12101] PEPs should have consecutive revision numbers
Georg Brandl ge...@python.org added the comment: The Last-Modified date should tell you just the same, without any arbitrary version numbers that don't have a meaning in hg. And behold, the Last-Modified date already links to the hg page for this PEP, from where you can select the file log to get to the list of changes. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12101 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12097] python.exe crashes if it is unable to find its .dll
anatoly techtonik techto...@gmail.com added the comment: Reopening as I believe the issue is hijacked. Virtualenv is just an example and the fix is discussed on its mailing list. This issue is about that Python interpreter is not self-contained, not portable, i.e. split into python.exe and pythonXX.dll The only reason for this split is to allow other programs use dynamic linking to load interpreter from .dll Such programs even though they are using pythonXX.dll from different .exe file do not crash. python.exe should not crash also. Moreover - as an open source project - it should serve as an example of proper linking to Python. It is not covered by PEP 397, because PEP is about launcher that chooses among multiple Python versions and this request about command line launcher for specific Python interpreter. But PEP 397 still can benefit from the research on this feature request - like explaining linking mechanism for developers. -- resolution: invalid - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12097 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9811] strftime strips '%' from unknown format codes on OS X
Marc-Andre Lemburg m...@egenix.com added the comment: Santoso Wijaya wrote: Santoso Wijaya santoso.wij...@gmail.com added the comment: `strftime` does not, indeed, seem to define what behaviour it is supposed to do when given non-supported format characters. Under Windows, in fact, it will crash the runtime (see: issue #10762). According to POSIX, it is defined to be undefined: If a conversion specification does not correspond to any of the above, the behavior is undefined. Of course, crashing the runtime is not a good way to interpret this ;-) -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12084] os.stat() on windows doesn't consider relative symlink
Georg Brandl ge...@python.org added the comment: Brian, do you think you'll be able to finish this for 3.2.1? If we do fix it, we'd need a second rc (not a problem for me). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12084 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12097] python.exe crashes if it is unable to find its .dll
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: You are right, the use case is broader than virtualenv. The only reason for this split is to allow other programs use dynamic linking For me the main reason is to support extension modules. On Windows, a DLL (or a .pyd) cannot resolve symbols in the main .exe program. Do you have more specifications about such a launcher? How would it find the .dll? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12097 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
