Re: [Python-Dev] Python3 and arm-linux
> > Somebody knowns, is python3 works on arm-linux. Is it possible to build it? > > Where to find related discussions? Maybe some special patches already > > available? Should i try to get sources from svn or get known version > > snapshot? > > > > I haven't tried, but there's an interesting distro at http://www.vanille- > media.de/site/index.php/projects/python-for-arm-linux/ -- I don't know if > other such distros have better-updated Python versions (eg. current 2.6.* > vs that one's 2.4.*) but that one includes a lot of very useful add-ons. You may want to look at the Ångström distro. http://www.angstrom-distribution.org/ http://www.angstrom-distribution.org/repo/?pkgname=libpython2.6-1.0 That's where I'll be heading in a couple of weeks. (I have a new BeagleBoard with an ARM Cortex-A8.) Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter release schedule?
>From the perspective of this application developer and prototyper... In general, releases should be more frequent when the language is less mature and perhaps lacking. With maturity one seeks stability and less frequency. Python is, for the most part, a mature language. I submit the issue is less a question of frequency, but more a question of the number and value of each of the new features. Too many new features added to a mature language begs the question of simplicity vs complexity. One of Python's original goals, if I recall correctly, was to keep life simple, to have executable psuedocode, be easy to learn and re-learn, and be able to quickly read and grok your code 6-12 months later. Ease of maintenance is a huge advantage of Python. From an application developer's perspective, too many confusing features and the language becomes more and more like C++ and APL. I submit Python is now at the point where new features must not be added just because they are cool, but because they indeed add significant value *without* compromising simplicity and the suite of "easy to" benefits. The alternative is to rethink the long-term goals for the language. That could have large unintended consequences. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
> The chances of a problem being introduced due to its removal > are vanishingly small. But that provides little consolation to the user who sees it in the standard library, is not aware to this discussion, and builds it into his app. Changes to the lib later may cause subtle but significant effects. ...perhaps undetected for a while. > > > I don't hear a public outcry - only a single complainer. > > > > Clay repeatedly pointed out that other people have objected > > to ipaddr and been ignored. It's really, really disappointing > > to see you continue to ignore not only them, but the repeated > > attempts Clay has made to point them out. > > I don't have time to argue this issue, but I agree with > essentially everything Clay has said in this thread I too agree. If it is not ready, it is not ready. Please don't create problems for others. Remove the lib until it is ready. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for Encrypted Zip as python scripts
I like the idea, but... Here is a quick list of things to think about and if some of this has already been mentioned, sorry. Speed: Encryption speed has been mentioned. For short scripts this may not be a problem, although algorithms implemented in C would be faster. Strength: Passwords are [very] weak, especially if of the 6-10 alphanumeric variety. True secret keys where all bit combinations are used is stronger. Entering passwords has been mentioned but I believe only passwords were assumed. It is better to not provide any encryption than to lure novices into believing they are secure when they are not. Algorithms: Be sure to choose good ones and allow for changing later. Key distribution: How to distribute secret keys beyond a small group of friends is problematic. In short it doesn't scale. Looking to public-private key pairs can be equally problematic. This can get you into encryption certs, but *how* you use them correctly differs from signing certs. More on this later if you want. ZIP: Look beyond just zip files. A scheme that works for any/all files in the distribution, not just ZIPs, would be better. (IIRC there have been problems with encrypted zips, but that was years ago. Those issues may have been fixed.) Short version: Doing this right is hard. Simply supporting a password based ZIP file is, in my opinion, not real protection. Gotta go. Later. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for Encrypted Zip as python scripts
> > I like the idea, but... > For what use case? I don't have a specific case in mind. In general, however, it would be nice to be able to protect intellectual property, but without addressing the problem from a holistic view, there is little protection afforded and perhaps a lot of unrewarded work. And I forgot one, Distribution of crypto across certain international borders. Export/import laws by itself can be a showstopper. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for Encrypted Zip as python scripts
I like the idea, but... >>> For what use case? >> I don't have a specific case in mind. In general, however, it >> would be nice to be able to protect intellectual property > This I'm also unclear about. How does it protect intellectual > property? Won't the person running the zipfile have to enter the > password? Whom would you protect the IP from? I agree the IP will have to be exposed at some point to be useful, but let's not overlook other things that could be in play like PIA agreements and the like. Also, something stronger than a password will be needed to be secure, and secret key distribution does not scale. There is a lot more to consider and we are only scratching the surface. Confidentiality in-the-large will take far more than encrypted ZIP files. Please know that I am not pushing for the encryption of ZIP files and this thread is going down a path I did not intend, or desire pursuing. My original post was intended to increase the awareness in those thinking encrypted ZIP files will 1) be easy, 2) afford the protection they desire, and 3) not lead others into a sense of false security. Encryption sounds good, but doing it right can be a landmine. A quick fix to support ZIP files will likely create more problems than it will solve. I still say it would be *nice* if there was some way to protect IP. I have no expectations that it will be easy, and least of all, solved by encrypted ZIP files and a simple patch to Python. ...but that should not diminish the desire. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
> > Do the users get any say in this?
>
> I'm a user! :-)
>
> I hate calling methods on string literals, I think it looks very odd
> to have code like this:
>
> "Displaying {0} of {1} revisions".format(x, y)
Ugh! Good point.
Is Python to be an easy-to-learn-and-remember language? I submit we are losing
that one. To a user, this will be confusing. To a C programmer coming over to
Python, especially so. Some of what makes %-formatting easy to remember is its
parallel in C.
I'm conflicted. Philosophically I like the idea of mnemonic names over
positional variables and allowing variable values determined elsewhere to be
inserted in print strings. It is appealing.
Unless the benefit is at least 2x, a change should not be made, and I don't
think this benefit rises to where it is worth the confusion and problems.
...and converting the legacy base. And forget pretty, not that %-formatting is
pretty either. Besides, according to the bench, it is slower too. And it will
take editors a while before the new syntax is supported and colorized, thus
some errors for a while.
...and if one wants a "{" or a "}" in the printed output, one has to escape it?
That is -2x over wanting a "%" in the output.
So until I see a *significant* benefit, my vote is *not* remove %-formatting.
Make both available and if {} is to win, it will.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
Greg Ewing wrote: > Having .py files around that aren't source text could lead > to a lot of confusion, given that most platforms these days > decide which application to open for a given file based > solely on the filename extension. I wouldn't enjoy trying > to open a .py file only to have my text editor blow up > because it was actually a binary file. > > So on balance I think it's a bit too kooky for my taste. +1 Add to that the inverse... I will cleanup directories based on the suffix keeping the .py and deleting .pyc and .pyo. Overloading a source file suffix is not good. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
Hi Barry, A question Do you know if OpenSSL's applink.c will be included in the Windows builds? If so, and I hope it is, great! If not, I'd like to encourage its inclusion. Doing so will permit Python to be used with OpenSSL 0.9.8x on Windows platforms without a user trying to find somebody with the right compiler to rebuild a Python for him/her. This is needed for M2Crypto, or any other OpenSSL wrapper for that matter. A lot more can be said here, but in the interest of brevity... ;-) applink.c is perhaps two dozen links and some error codes, and is benign for those not calling these APIs. applink.c may be found in /ms and the one line include stmt that would be added to /Modules/python.c is: #include "/applink.c" That's it. And the OpenSSL FAQ: http://www.openssl.org/support/faq.html#PROG2 Tx, Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
> I don't understand how applink is going to help you. The SSL libs are statically linked > into the _ssl extension DLL. I personally have not used _ssl but on quick inspection I don't see any of the crypto algorithms implemented, AES, ECDSA, etc. What if we want to encrypt or sign content using OpenSSL? We'd import M2Crypto but when we go to load the key we'll get an OPENSSL_Applink error. Likewise for OpenSSL with xmlsec. Larry PS: This problem applies to vanilla builds of Python on Windows only when Microsoft tools and libraries are used to build Python. It does not apply to cygwin or mingw where gcc is used. Likewise, it does not apply to other platforms, only Windows. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
> I don't understand how applink is going to help you. The SSL libs are statically linked > into the _ssl extension DLL. I personally have not used _ssl but on quick inspection I don't see any of the crypto algorithms implemented, AES, ECDSA, etc. What if we want to encrypt or sign content using OpenSSL? We'd import M2Crypto but when we go to load the key we'll get an OPENSSL_Applink error. Likewise for OpenSSL with xmlsec. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
I appreciate the gesture but... At this juncture I'd prefer to see OpenSSL access to crypto APIs remain an external library like M2Crypto, at least until the Python community is willing to do a full implementation of all OpenSSL APIs. ...and maintain it. Larry -Original Message- From: Bill Janssen [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 10:14 AM To: Bugbee, Larry Cc: Christian Heimes; python-dev@python.org Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c? > I personally have not used _ssl but on quick inspection I don't see > any of the crypto algorithms implemented, AES, ECDSA, etc. What if we > want to encrypt or sign content using OpenSSL? I suggested adding a class which gives you access to those. I think it's a good idea, and that serious use of SSL will require signing eventually. If you'd like to submit an RFE, particularly an RFE with a patch which includes a test case, that would move things along smartly. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
I won't pretend to know where the *best* place to put the include is, but python.c was suggested to me some time ago. Just so you know, we tried putting the include in some C code that is part of M2Crypto and it did not work because, as we discovered, the applink table needs to be part of main(). Extending that thought... If somebody wanted to somehow embed python is part of the same process in their program as with perhaps IIS, I submit it would not be part of main() and therefore benign. Now, I would like very much to be in a position to experiment with all the combinations and prepare a patch that worked, but I do not have the requisite Microsoft toolset. I primarily work with gcc under OSX, Linux, cygwin/mingw. This last raises a curiosity question. Is there a reason why Python.exe cannot be built using gcc instead of Visual Studio? Would not requiring the same VS version cause a problem in the field if someone were to receive an extension but had their Python built using a different version of VS? It seems building everything with gcc would get around the problem of having to match VS versions. ...or are we dependent on some specific Microsoft library? I dunno, I gotta ask. Larry -Original Message- From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:10 PM To: Christian Heimes Cc: Bill Janssen; Bugbee, Larry; python-dev@python.org Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c? > Do you have an opinion on the initial proposal of applink.c? > The proposal does neither seem harmful nor problematic but I > also don't see how it is going to help the op. The specific change isn't going to help. What could help is the inclusion of applink.c into dl_nt.c. This is not about somehow exposing SSL routines to other libraries, but about exposing CRT stuff to openssl, specifically stdin/stdout/stderr, fprintf, fgets, fwrite, fsetmod, feof, ferror, clearerr, fileno, _open, _read, _write, _lseek, _close. Actually, re-reading OpenSSL, adding it to python.exe (and probably pythonw.exe) would help: They do GetModuleHandle(NULL) (which is the handle to the executable), then GetProcAddress for OPENSSL_Applink. So I think it's harmless and could help, except for the maintenance burden of having to update our local copy of applink.c every time OpenSSL adds a new slot to their applink table (which they should rarely do). Of course, the entire approach breaks in cases where Python gets embedded: if, e.g., IIS loads the Python interpreter as a COM scripting host, it would be the IIS executable which would have to include applink.c :-) As IIS doesn't, extension modules that link with their own OpenSSL will continue to produce a warning about the missing applink when they run in the context of a COM server (or some other Python embedding). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Gerald, if there is an expectation some of your HP windows users would like to use OpenSSL with Python, there is this little matter of including applink.c in the build. All, and not to start flames, but I still do not understand why applink.c isn't included in python's main (conditionally) instead of expecting users, many of them novices, to do the build. ??? Larry [snip] Message: 2 Date: Wed, 26 Nov 2008 19:06:44 + From: "Koenig, Gerald" <[EMAIL PROTECTED]> Subject: [Python-Dev] Python for windows. To: "python-dev@python.org" Message-ID: <[EMAIL PROTECTED] net> Content-Type: text/plain; charset="us-ascii" Hi all, I am working For Hewlett-Packard designing PC Consumer Desktop We have been including Python since over 10 years now on our systems. It is a wonderful language and very powerful. Now I am having a small issue and I was wondering how I can solve it. So I would like to know who should I contact to be able to work on that issue together ? The issue is about some requirement I need to have on our systems and even tools need to pass those requirement. Regards Gerald Koenig Software Builds Architect Hewlett-Packard Work Phone: +(1) 408 873 6202 -- [snip] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> > All, and not to start flames, but I still do not understand why > > applink.c isn't included in python's main (conditionally) instead > > of expecting users, many of them novices, to do the build. ??? > > One reason is that I don't know what applink is, and why I should > care about it. (I may have known in the past, but then I have > forgotten since). Yeah, it's been a while for me too. As I recall, OpenSSL, a long while ago stopped, supporting some idiosyncrasies associated with Windows I/O and opted for a "cleaner" approach, that of requiring developers to link a small file, applink.c, into the app's main. applink.c is provided by the OpenSSL folks. >From http://www.openssl.org/docs/crypto/OPENSSL_Applink.html: OPENSSL_Applink is application-side interface which provides a glue between OpenSSL BIO layer and Win32 compiler run-time environment. Even though it appears at application side, it's essentially OpenSSL private interface. For this reason application developers are not expected to implement it, but to compile provided module with compiler of their choice and link it into the target application. The referred module is available as /ms/applink.c. For most custom apps this is a simple process of adding "#include applink.c" to the app's main(). The problem for Python developers is that their Python program is not main(), and if python.exe does not have the OPENSSL_Applink interface, they cannot import M2Crypto, pyOpenSSL, or use ctypes to wrap OpenSSL, and write a PEM file without throwing an error. (That said, Daniel Clark says he is not experiencing problems with NCrypt. I have not verified.) One solution is for those users to build their own Python from scratch. Many/most cannot do it, especially if they don't have the right version of Visual Studio. I know I don't. I simply stopped developing on Windows. Arguably better is to have the include statement in the python source file, python.c, appropriately conditioned. ...and to provide a copy of applink.c. That way, there would be no more need to try to find or do a custom build. Everybody building for a Windows platform will have applink included and access to OpenSSL becomes a non-issue. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Not necessarily. I have no problems with hashlib or Python/M2Crypto/OpenSSL as long as I'm doing memory-oriented operations. It is only when the function does I/O that errors occur. ...like reading/writing a PEM file, randpool.dat, etc. -Original Message- From: Bill Janssen [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2008 5:54 PM To: Bugbee, Larry Cc: "Martin v. Löwis"; Koenig, Gerald; python-dev@python.org Subject: Re: [Python-Dev] Python for windows. Bugbee, Larry <[EMAIL PROTECTED]> wrote: > For most custom apps this is a simple process of adding "#include > applink.c" to the app's main(). The problem for Python developers is > that their Python program is not main(), and if python.exe does not > have the OPENSSL_Applink interface, they cannot import M2Crypto, > pyOpenSSL, or use ctypes to wrap OpenSSL, and write a PEM file without > throwing an error. (That said, Daniel Clark says he is not > experiencing problems with NCrypt. I have not verified.) I'm probably missing something here. Python 2.6/3.x uses OpenSSL for the hashlib and ssl modules. Doesn't this mean that this applink.c file is part of the standard build now? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> > > All, and not to start flames, but I still do not understand why > > > applink.c isn't included in python's main (conditionally) instead > > > of expecting users, many of them novices, to do the build. ??? > > > > One reason is that I don't know what applink is, and why I should care > > about it. (I may have known in the past, but then I have forgotten > > since). > > Yeah, it's been a while for me too. > > As I recall, OpenSSL, a long while ago stopped, supporting some > idiosyncrasies associated with Windows I/O and opted for a "cleaner" > approach, that of requiring developers to link a small file, applink.c, > into the app's main. applink.c is provided by the OpenSSL folks. This is a years old issue and while I periodically revisited and confirmed the problem remained (again as late as a month or two ago), all of this is from memory and I cannot tell you version numbers and the like. Before pursuing further, I should do virgin installs and test again. I'll report back my findings in a couple of days, either way. My thanks, Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3.0, unicode, and os.environ
There has been some discussion here that users should use the str or byte function variant based on what is relevant to their system, for example when getting a list of file names or opening a file. That thought process really doesn't do much for those of us that write code that needs to run on any platform type, without alteration or the addition of complex if-statements and/or exceptions. Whatever the resolution here, and those of you addressing this thorny issue have my admiration, the solution should be such that it gives consistent behavior regardless of platform type and doesn't require the programmer to know of all the minute details of each possible target platform. That may not be possible for a while, so interim solutions should be such that it minimizes later pain. If that means hiding "implementation details" behind a new function, so be it. Then, at least, the body of one's app is not burdened with this problem later when conditions change. I'm glad I'm not the only one with hard problems. ;-) Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3.0, unicode, and os.environ
> I'm perhaps biased here; most of my Python programs don't have user > interfaces, because they don't "talk" to people, they talk to other > programs. The binary APIs for the OS are essential. I use and > deeply appreciate all the string handling features in Python, > particularly its firm grip on Unicode issues, but that's *useful* > instead of *essential*. Exactly! Another +1. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
