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 m
> > 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 submi
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 t
> > 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 wo
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 [
> 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
ef
>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
> > 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 dis
> 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 g
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 a
> > > 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
> >
nssen [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
> > 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
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) inste
osoft 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
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
> a
> 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
> 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
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 someb
19 matches
Mail list logo
