Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Hi everyone,

which compiler will Python 2.5 on Windows (Intel) be built with? I
notice that Python 2.4 apparently has been built with the VS2003
toolkit compiler, and I read a post from Scott David Daniels [1] where
he said that probably the VS2003 toolkit will be used for Python 2.5
again. However, even before the release of Python 2.5, I cannot seem to
find many retailers around here that still carry Visual Studio 2003,
and some were a bit surprised about my request since Visual Studio 2005
has been available for some months now. Even more importantly, there
does not seem to be an official way to still get the 2003 toolkit from
Microsoft. The site where it used to be available [2] now redirects you
to the 2005 toolkit. The 2003 toolkit also seems to have disappeared
from the browseable downloads on the Microsoft page. Searching for
VCToolkitSetup.exe on the net, I found a few pages that still appear to
carry the file, but most are down or just redirect to a broken link on
the Microsoft site. That means that if Python 2.5 will be based on the
2003 toolkit compiler, it will be increasingly difficult to get a
compiler for extensions.

Since we have some Python extensions here that use MFC internally (MFC
is only available in the retail version of Visual Studio .NET), we need
to know in which compiler we have to invest to keep our extensions
compatible with Python 2.5. Furthermore, since we also have legacy C++
applications that link to the same libraries that are also used in the
Python extensions, we would be disappointed when we now had to switch
to Visual Studio 2003 just to be compatible with Python 2.5, loosing
official support from Microsoft in near future, and having to use an
outdated compiler throughout the lifetime of Python 2.5.

Thanks in advance for your comments!
Markus Meyer

[1] Google Groups: Python 2.5 Schedule (18 messages)
http://groups.google.ca/group/comp.lang.python/browse_thread/thread/2f8be89236999a37/f6f95174484c24cc?hl=en

[2] Microsoft Visual C++ Toolkit 2003
http://msdn.microsoft.com/visualc/vctoolkit2003/

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Scott,

Scott David Daniels wrote:
> [EMAIL PROTECTED] wrote:
> > Hi everyone,
> >
> > which compiler will Python 2.5 on Windows (Intel) be built with?
>
> Same as for Python 2.4 (the decision was taken a while ago).
> Intel sells a compatible compiler, I believe.

the problem is not the ABI, but the runtime libraries. From what you're
saying, it looks like we will have to standardize on VS2003. As I said,
we need to buy VS anyway because of the MFC support. On the other hand,
I really worry about all those people that want to build open source
extensions for Python 2.5. It is really possible that there will be no
legal, free way to do that soon if you don't have an old installation
of the 2003 toolkit lying around somewhere... So I'd like to ask you:
why was the decision taken a while ago (and is not subject to
reconsideration) and what are the reasons for using VS2003? I mean
there must be a real good reason why you're doing this, as I only see
disadvantages in it.


Markus

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Mr Roboto wrote:
> I haven't personally tried a Python compile w/ this, but I'll
> share it in hopes that it'll help:  one can download a free copy
> of Visual C++ 2K5 *Express* from microsoft itself.  If you're
> interested, try:

The problem is, when you compile an extension module with VS (Express)
2005 and try to load it in a VS2003-compiled Python (which apparently
2.5 will be), there will be errors. So you have to recompile Python
itself with VS2005. This in turn will make it incompatible with any
binary open-source extension out there. E.g., if you use wxPython, you
will then have to recompile that also etc. pp. Also, since there is no
"official" support for the build with VS 2005, it is not clear, if the
differences in the compiler will introduce subtile bugs, say in memory
handling and the like. All in all, this situation feels not good to
me...


Markus

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Hi Scott,

thanks for keeping up the friendly discussion. Comments below.

Scott David Daniels wrote:
> The disruption in Python 2.4 in switching from one compiler (VC6) to
> another VS2003 was not insubstantial.  By sticking with VS2003, sometime
> users can at least use the same tool for Python 2.4 and Python 2.5.  It
> does seem inevitable we will have to switch for 2.6.  We are very far
> along in the process of releasing Python 2.5 (beta1 is due out soon),
> and rebuilding and testing with a new translation system is too big a
> change at this point.

I understand that you are far in the release cycle and that this change
would maybe even delay the whole release process. Those are good
points. OTOH I think that sometimes it's better to change decisions in
light of new facts. Of course I don't know exactly when this decision
was fixed, but I guess since then Microsoft has created two new facts
that cannot be ignored:

* It wasn't clear that Microsoft would stop distributing the free 2003
toolkit in favor of the 2005 toolkit. I cannot remember that they did
something like this in the past, so this is something that came as a
surprise.

* At least to me it wasn't clear that Microsoft would release a new
version of Visual Studio so early, and that it would link to a new,
incompatible C runtime.

One can like or not like Microsoft politics, but I think in case of
those new and surprising facts a re-evaluation of the decision for
compiling Python with VS2003 might very well be justified.

> Note there was strong resistance to leaving VC6 for Python 2.4.  That
> resistance was overcome only by the fact that it was no longer possible
> to purchase suitable versions of VC6.

I'm not sure how that backs the point you made. Infact, you're saying
that people accepted that Python 2.4 was compiled with VS2003 because
VC6 could not longer be bought. How is that different from the current
situation where the VS2003 toolkit cannot longer be downloaded and it
is at least becoming increasingly difficult to buy versions of VS2003?
You also seem to imply that there is a large group of people that want
you to stay with VS2003 for compiling Python 2.5. Of course I have no
actual figures, but at least in this thread it seems to me that every
single person who wrote in this thread until now was pro-2005 and
against-2003.


Markus

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Hi Fredrik,

first, thanks for PIL, I use it extensively in my daily work ;)

Fredrik Lundh wrote:
> huh?  2.5 isn't released yet.  if you *have* a Python app, you can
> continue to use the same compiler when you upgrade from 2.4 and 2.5.
> it's not like anyone is forcing you to uninstall the compiler just
> because you upgrade Python...

No, but the compiler that used to be available for compiling 2.4
extensions is no longer available and/or supported. So there is/was
hope that 2.5 might improve the situation because then compiling
extensions would be possible again with the currently available
compiler from Microsoft. This would require that Python 2.5 be built
with this compiler of course. So the situation is actually worse than
before (when the 2003 toolkit was available), and the decision for 2003
means that it won't improve with the release of 2.5. I believe this is
what the gp was trying to say...


Markus

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Fredrik,

Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
> > I'm not sure how that backs the point you made. Infact, you're saying
> > that people accepted that Python 2.4 was compiled with VS2003 because
> > VC6 could not longer be bought. How is that different from the current
> > situation where the VS2003 toolkit cannot longer be downloaded and it
> > is at least becoming increasingly difficult to buy versions of VS2003?
> > You also seem to imply that there is a large group of people that want
> > you to stay with VS2003 for compiling Python 2.5.
>
> what part of "Python 2.4 is built with VC2003 and everyone who's ever
> built Windows stuff for Python 2.4 already has it" do you have trouble
> understanding ?

I'm actually a bit disappointed that this thread is slowly turning into
a flame-war (and you would not be uninvolved when it does so). I
originally only wanted to create a discussion on a simple topic. I
understand that the Python community is exactly that -- a community
where people voice their opinion and the result of a discussion will
ultimately be a consensus that is followed. I do understand that a
decision on the issue at stake has already been made, but as I
explained in the GP I think that this is a decision that one might
re-evaluate in light of new facts created by a third party (Microsoft).
In any case, there's no reason to get hot about the topic.

But responding to your original question, let me give an example so
maybe you can see my point a bit clearer. I have a customer where I
recently had to add a feature to a Python 2.4 extension. About a year
ago, I wrote the extension, downloaded the 2003 toolkit from Microsoft,
compiled the extension and installed it on the customer's site. Since
then, I got a new laptop, and I never installed the 2003 toolkit again,
because all my other software is in either pure Python or pure Visual
C++ 6 w/ MFC. So I was at the customer's site and discovered that the
2003 toolkit is no longer available at Microsoft. Bummer! Since it is
an important customer, I decided to phone around in the customer's city
if any shop had a version of Visual Studio 2003 lying around so I would
be able to compile the extension. They all would have readily sold me
Visual Studio 2005, but had no 2003 in stock. Second bummer! What I'm
trying to make here are two points:

* Using outdated development tools for new releases is just begging for
difficulties. Python 2.5 will be out there some time, and it will be
increasingly difficult to get VS 2003. The support for VS 2003
(including support for security holes) will probably expire during the
lifetime of Python 2.5. It's like releasing a Python 2.5 that does not
work on Windows XP, only on Windows 2000.

* There is currently a very good optimizing free (as in beer) compiler
available for the Windows platform: The VS Toolkit 2005. But you won't
be able to write extensions for Python 2.5 with this compiler. That's a
pity for the Open Source community as whole, as many Open Source
developers cannot afford to buy a commercial compiler (and many won't
do it even if they could). Note that this is different from the
situation we had a year ago. A year ago, we could download the 2003
toolkit and build extensions for Python 2.4. Now, when Python 2.5 comes
out, we cannot download the 2003 toolkit anymore. Therefore, we cannot
build extensions for 2.4, but not for 2.5 either. Of course those that
still have an install of the 2003 toolkit lying around are happy -- but
only until the next reinstall of their OS.


Markus

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Scott,

thanks for your clear words.

Scott David Daniels wrote:
> Nor was it clear to the PyDev community.  Microsoft offered free
> development systems to those among the PyDev group who were core
> developers, and we took that offer.  At the time we had no idea
> it was on such a short-windowed product.  VC6 lasted a _long_ time.

Hmm, I see

> As nikie pointed out, you can buy a 1-year MSDN Pro Subscription that
> includes the VS2003 system.  All that stopped is the free toolkit.

The MSDN Pro Subscription is not really an option because we have no
use for the 2005 compiler at all if it doesn't work with Python. I
think we'll just try to get some boxed version of Visual Studio 2003
Professional from somewhere.

> Taking percentages of people who complain is not reflect necessarily
> reflective of percentages of the general population.

Of course you're right, but still I think you will get lots of
complaints once 2.5 is out and people realize that they (again) have to
buy a compiler to compile extensions. Don't get me wrong, it's not a
problem for me, but it will be a problem for other people.

>  If I recall
> correctly, there was some angst about using VC6, because it was only
> available for a hefty-for-hobbyists price.  That was quelled with the
> explanation that essentially all Windows developers used the Visual
> Studio toolkit.

The difference here is that back then one had no other option than to
buy the compiler. Today, there _is_ a free Microsoft compiler
available, but it unfortunately is the wrong one.

> As to MinGW, nobody has signed up to commit long-term to doing the PyDev
> work that is required to get (and keep) it working.  Such a developer
> would be welcome.  There _are_ notes out there on the web to help you
> get such things going; I have done my own little bit to share what I
> know about how to do that.

As for what compiler vendor to use, I agree that it is the right
decision to use the Microsoft compiler on Microsoft platforms even if
it means buying it. GCC is not really an alternative on Windows.


Markus

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

> This is the .NET 11 SDK, I belive it includes the 2003 compiler (*):

Last time I checked the .NET SDK they had the C# compiler in there, but
not the C++ optimizing 2003 compiler. Might be wrong though

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Martin,

thanks for the tip, I wasn't fully aware of that. OTOH, though GCC
might be a theoretical alternative, it isn't a practical one for many
situations:

* In a professional environment, it opens up another can of potential
problems, where one would rather like to stay with one single
compiler/build system.
* I suppose Python's distutils have to be tweaked to work with GCC
* The Makefiles/build system will need to be changed to work with the
GCC toolchain
* The different semantics of GCC and Microsoft C often need rewriting
some of the code
* There is no support for MFC/ATL in GCC
* The code created by the Windows GCC is not as good as the one created
by the Microsoft compiler


Markus

Martin v. Löwis wrote:
> [EMAIL PROTECTED] wrote:
> > the problem is not the ABI, but the runtime libraries. From what you're
> > saying, it looks like we will have to standardize on VS2003. As I said,
> > we need to buy VS anyway because of the MFC support. On the other hand,
> > I really worry about all those people that want to build open source
> > extensions for Python 2.5. It is really possible that there will be no
> > legal, free way to do that soon if you don't have an old installation
> > of the 2003 toolkit lying around somewhere...
>
> As others have pointed out already: This is not true. You can build
> Python extensions with GCC just fine; gcc provides an import library
> for msvcr71.dll.
>
> It might be possible to integrate an msvcr71.dll import library
> with VS 2005, in which case you could use VS 2005 to create Python
> extensions as well.
> 
> Regards,
> Martin

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Martin,

Martin v. Löwis wrote:
> > * In a professional environment, it opens up another can of potential
> > problems, where one would rather like to stay with one single
> > compiler/build system.
> That's a theoretic argument to me: Can you name four or five problems
> out of that can?

In bigger (i.e. real-world) projects, it can be a lot of hassle
switching to another compiler, even from the same vendor. Of course, in
theory C and C++ compilers should be compatible, but in practice
there's lots of small things that are implemented differently. Among
them are #pragmas, the support for precompiled headers, template
instantiation, different semantics for "half-legal" constructs etc.
Also, some syntactic constructs which compile on one compiler are
rejected by another compiler. Further, often code implicitely depends
on the behaviour of one single compiler, although the developer doesn't
really know that. Of course you can cry fool on the developer that
wrote the code and blame him for not following the C-whatever spec, or
not using the "correct" way to do X, but fact is, there's always stuff
that will not work when switching to another compiler. And there's a
bunch of other stuff that will appear to work but "activate" bugs in
the control structure that were there previously but luckily did not
manifest with the other compiler.

Btw, the same goes for different versions of libraries, say different
versions of wxWidgets, MFC, Visual Basic (anyone tried to switch from
VB6 to VB.NET?) and of course also for different versions of Java and
its libraries.

> > * The Makefiles/build system will need to be changed to work with the
> > GCC toolchain
>
> If you are using distutils, you don't need a Makefile, and the
> setup.py won't have to be tweaked. If you are not using distutils,
> but, say, nmake already, then you will already have an earlier version
> of the compiler - how else did you create the nmake files in the first
> place?

We have lots of stuff written in VC++6 which is not
distutils-compatible, and we can't really switch that code over to GCC
anytime soon, see above. All in all, we would end up compiling
something with VC, linking it with GCC to another VC app (Python). No,
thanks.

> Still, if you really cannot use gcc, then go ahead and compile with
> VS 2005. Just make sure you link with mscvr71.dll. If you absolutely
> need that to work, you will find a way to make it work.

The question is, is it cheaper and more hassle-free to spend the time
to "find a way to make it work" and hope everything goes smoothly
(remember, the fact, that it says "Linker results: 0 errors / 0
warnings" does not mean that the app will work as expected and as
tested before) or to buy VC (which costs a mere few hundred dollars).

Bottom Line: As I said before, I don't have a problem using VC2003 or
anything. It's by far the cheapest and easiest way just to buy VC2003
and be done with it, than to fiddle around with GCC or anything. I just
think that Python should use the best technology available at the time
of release, which is VC2005 on Windows. But as I indicated before, of
course I do understand the argument that the release cycle has already
been planned and should not be changed, so we'll just live with it as
it is now.


Markus

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

Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer]

Roel Schroeven wrote:
> [EMAIL PROTECTED] schreef:
> > * The code created by the Windows GCC is not as good as the one created
> > by the Microsoft compiler
>
> Isn't Python for other platforms built with GCC? Seems to me that if it
> GCC is good enough for other platforms, it's good enough for Windows.

Actually, GCC on Linux does provide worse machine code than say, the
Intel compiler for Linux. This is not a "bug" of GCC, but a feature,
because GCC was created for maximum portability and flexibility, not
for maximum performance on one single platform like the Intel compiler.
But GCC is truly free and can be distributed easily (because it's GPL),
so it is the default compiler for most (if not all) distros at the
moment. Also, there are many free software programs that use special
features of GCC and cannot be compiled using another compiler.

Of course I do acknowledge that often in the real world the IO forms
the bottleneck of a system and the efficiency of the machine code is
somewhat neglegible (other posters pointed that out already).


Markus

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

Re: 10 sec poll - please reply!

[Alan Meyer]

On 11/20/2012 11:29 AM, mherrmann...@gmail.com wrote:

> ... generate_keystrokes?  ...

Not bad.  "gen_keystrokes", or even "keystrokes" might also do.

I suggest using a name that is unique enough that you can grep through 
piles of code and find where it's used.  "type" fails that test. 
"generate_keystrokes" passes with flying colors, but may be overkill.


Alan

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

Re: list comprehension to do os.path.split_all ?

[Alan Meyer]

On 7/28/2011 4:18 PM, gry wrote:

[python 2.7] I have a (linux) pathname that I'd like to split
completely into a list of components, e.g.:
'/home/gyoung/hacks/pathhack/foo.py'  -->   ['home', 'gyoung',
'hacks', 'pathhack', 'foo.py']

os.path.split gives me a tuple of dirname,basename, but there's no
os.path.split_all function.

I expect I can do this with some simple loop, but I have such faith in
the wonderfulness of list comprehensions, that it seems like there
should be a way to use them for an elegant solution of my problem.
I can't quite work it out.  Any brilliant ideas?   (or other elegant
solutions to the problem?)

-- George


This is not properly portable to all OS, but you could simply split on 
the slash character, e.g.,


pathname.split('/')

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

Re: Only Bytecode, No .py Files

[Alan Meyer]

On 07/26/2011 11:19 AM, Eldon Ziegler wrote:

Is there a way to have the Python processor look only for bytecode
files, not .py files? We are seeing huge numbers of Linux audit messages
on production system on which only bytecode files are stored. The audit
subsystem is recording each open failure.

Thanks,
Eldon Ziegler


Here are two suggestions:

1. Put a dummy python file in the directory that does very little, 
perhaps something like:


   print("%s: You should not be seeing this" % sys.argv[0])

Give it the name of one of the .pyc, e.g., if foo.pyc, then foo.py.

Give the bytecode file a later date, e.g., "touch foo.pyc" (assuming you 
can do that without messing up other aspects of your system.)


If that works, then copy the dummy file to each of the other required 
.py names in the directory.  You'll then have to touch *.pyc to ensure 
that the pyc's have later dates.  After that, you won't have to do 
anything when you replace a .pyc file.  When you add a new .pyc you'll 
need to do the copy and touch again.


2. Use a log truncator to truncate the audit log.

I don't remember the name of one at the moment, but I believe there is 
at least one open source program that will monitor named files and 
truncate them from the beginning to a fixed maximum size.


I don't like this method as much as the first because it might result in 
something important being truncated.


Alan

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

Re: Another win for profiling.

[Alan Meyer]

On 07/29/2011 07:46 AM, Roy Smith wrote:

It's often said that you shouldn't try to guess what's slow, but use
profiling tools to measure what's slow.  I had a great example of that
yesterday.  ...


Yes.

My first experience of profiling was about 25 years ago.  I was 
experimenting with Borland's Turbo Profiler on C code.  I thought to 
myself, What kind of clueless programmer doesn't know where his code is 
spending its time?  How useful could this be?


Then I ran the profiler and found out how clueless I really was.  The 
profiler showed me that I could change one line in a thousand line 
program and cut the run time by 50%.


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

Re: Instant File I/O

[Jordan Meyer]

That did the trick! Thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Directly Executable Files in Python

[Jordan Meyer]

Is it possible to make a directly executable (such as .exe on Windows) file 
from scripts written in Python? So as to prevent the end-user from having to 
download an interpreter to run the program.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Composition instead of inheritance

[Alan Meyer]

On 4/28/2011 1:15 PM, Ethan Furman wrote:

For anybody interested in composition instead of multiple inheritance, I
have posted this recipe on ActiveState (for python 2.6/7, not 3.x):

http://code.activestate.com/recipes/577658-composition-of-classes-instead-of-multiple-inherit/


Comments welcome!

~Ethan~


That looks pretty clever.  I tried adding this method to Spam:

def test_eggs_02(self):
print('testing eggs_02 from spam')

and it did just what we wanted.

I'm going to have to study this one.

Thanks.

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

Re: recursive methods require implementing a stack?

[Carl Meyer]

On 04/06/2016 03:08 PM, Random832 wrote:
> On Wed, Apr 6, 2016, at 16:21, Charles T. Smith wrote:
>> I just tried to write a recursive method in python - am I right that
>> local
>> variables are only lexically local scoped, so sub-instances have the same
>> ones?  Is there a way out of that?  Do I have to push and pop my own
>> simulated
>> stack frame entry? 
> 
> No, and I'm not sure why you would think that.

Sounds like a confusion that might arise due to using a mutable default
arg? Or generally passing a mutable arg and not understanding Python's
calling semantics?

Carl



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

Re: pytz and Python timezones

[Carl Meyer]

Hi Johannes,

On 06/11/2016 05:37 AM, Johannes Bauer wrote:
> I try to create a localized timestamp
> in the easiest possible way. So, intuitively, I did this:
> 
> datetime.datetime(2016,1,1,0,0,0,tzinfo=pytz.timezone("Europe/Berlin"))

That is indeed intuitive, but unfortunately (due to a misunderstanding
between the original authors of Python's datetime module and the author
of pytz about how timezone-aware datetimes should work in Python) it is
not correct. The correct way to create a localized datetime using pytz
is this:

tz = pytz.timezone('Europe/Berlin')
dt = tz.localize(datetime.datetime(2016, 1, 1, 0, 0, 0)

This is documented prominently in the pytz documentation:
http://pytz.sourceforge.net/

> Which gives me:
> 
> datetime.datetime(2016, 1, 1, 0, 0, tzinfo= LMT+0:53:00 STD>)
> 
> Uh... what?

When you create a pytz timezone object, it encompasses all historical
UTC offsets that have ever been in effect in that location. When you
pass a datetime to the `localize()` method of that timezone object, it
is able to figure out which actual UTC offset was in effect at that
local time in that location, and apply the correct "version" of itself
to that datetime.

However, no such logic is built into the datetime module itself. So when
you just apply a pytz timezone directly to the tzinfo property of a
datetime, pytz by default falls back to the first entry in its
historical table of UTC offsets for that location. For most locations,
that is something called "LMT" or Local Mean Time, which is the
customary time in use at that location prior to the standardization of
timezones. And in most locations, LMT is offset from UTC by a strange
number of minutes. That's why you see "LMT" and the odd 53-minute offset
above.

> This here:
> 
> pytz.timezone("Europe/Berlin").localize(datetime.datetime(2016,1,1))
> 
> Gives me the expected result of:
> 
> datetime.datetime(2016, 1, 1, 0, 0, tzinfo= CET+1:00:00 STD>)
> 
> Can someone explain what's going on here and why I end up with the weird
> "00:53" timezone? Is this a bug or am I doing things wrong?

It is not a bug in pytz or in datetime, in that it is intended behavior,
although that behavior is unfortunately obscure, bug-prone, and
little-understood.

If you are masochistic enough to want to understand how this bad
situation came to be, and what might be done about it, you can read
through PEPs 431 and 495.

Carl



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

Re: How well do you know Python?

[Carl Meyer]

On 07/05/2016 05:50 AM, Chris Angelico wrote:
> On Tue, Jul 5, 2016 at 9:33 PM, Peter Otten <__pete...@web.de> wrote:
>> Chris Angelico wrote:
>>
>>> On Tue, Jul 5, 2016 at 6:36 PM, Peter Otten <__pete...@web.de> wrote:
 What will

 $ cat foo.py
 import foo
 class A: pass
 print(isinstance(foo.A(), A))
 $ python -c 'import foo'
 ...
 $ python foo.py
 ...

 print?
[snip]
>> The intended lesson was that there may be two distinct classes
>>
>> __main__.A and foo.A
[snip]
> The two distinct classes problem is a very real one, and comes of
> circular (or not-technically-circular, as in the second case) imports.

It can also come of pathological setups where a path and its parent are
both on sys.path, so all import paths have an "optional" prefix (but you
actually get a different copy of the module depending on whether you use
that prefix).

Carl



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

Re: Sniffing Text Files

[Mike Meyer]

David Pratt <[EMAIL PROTECTED]> writes:

> Hi. I have files that I will be importing in at least four different
> plain text formats, one of them being tab delimited format, a couple
> being token based uses pipes (but not delimited with pipes), another
> being xml. There will likely be others as well but the data needs to
> be extracted and rewritten to a single format. The files can be fairly
> large (several MB) so I do not want to read the whole file into
> memory. What approach would be recommended for sniffing the files for
> the different text formats. I realize CSV module has a sniffer but it
> is something that is limited more or less to delimited files.  I have
> a couple of ideas on what I could do but I am interested in hearing
> from others on how they might handle something like this so I can
> determine the best approach to take. Many thanks.

With GB memory machines being common, I wouldn't think twice about
slurping a couple of meg into RAM to examine. But if that's to much,
how about simply reading in the first  bytes, and checking that
for the characters you want?  should be large enough to reveal
what you need, but small enogh that your'e comfortable reading it
in. I'm not sure that there aren't funny interactions between read and
readline, so do be careful with that.

Another approach to consider is libmagic. Google turns up a number of
links to Python wrappers for it.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Mike Meyer]

"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> Agreed; python-dev has gotten pretty boring with all the endless discussions
> over some minor point.  Of course, it's much easier and lower-effort to
> propose a syntax or nitpick a small point issue than to tackle a big
> complicated issue like static typing.  
>
> Similar things happen on the catalog SIG: people suggest, or even implement,
> an automatic package management system, But bring up the question of whether
> it should be called PyPI or Cheeseshop or the Catalog, and *everyone* can make
> a suggestion.

This is a well-known phenomenon, having picked up the name "bikeshed"
something like 40 years ago. Google for "bikeshed color". Or just
check out the FreeBSD FAQ entry at http://www.bikeshed.com/ >.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sniffing Text Files

[Mike Meyer]

David Pratt <[EMAIL PROTECTED]> writes:
> Thanks Mike for your reply.  I am not aware of libmagic and will look
> to see what it provides.

and ...

Skip Montanaro <[EMAIL PROTECTED]> writes:
> You can also run the file(1) command and see what it says.  I seem
> to recall someone asking about the equivalent to file(1) implemented in
> Python awhile back.  

libmagic is the smarts of the file command. As I said before, people
have done Python wrappers for it. It uses a text database describing
how to recognize a files type - see the magic(5) man page for details
on that. If you use libmagic, you'll probably want to provide your own
version of the databse, excerpted to include just the file types you
want to recognize.

You can check on whether or not this will work for you by seeing what
the file command says about your sample data.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Parsing an HTML a tag

[Mike Meyer]

"beza1e1" <[EMAIL PROTECTED]> writes:

> I do not really know, what you want to do. Getting he urls from the a
> tags of a html file? I think the easiest method would be a regular
> expression.

I think this ranks as #2 on the list of "difficult one-day
hacks". Yeah, it's simple to write an RE that works most of the
time. It's a major PITA to write one that works in all the legal
cases. Getting one that also handles all the cases seen in the wild is
damn near impossible.

import urllib, sre
html = urllib.urlopen("http://www.google.com";).read()
sre.findall('href="([^>]+)"', html)

This fails in a number of cases. Whitespace around the "=" sign for
attibutes. Quotes around other attributes in the tag (required by
XHTML). '>' in the URL (legal, but disrecommended). Attributes quoted
with single quotes instead of double quotes, or just unqouted. It
misses IMG SRC attributes. It hands back relative URLs as such,
instead of resolving them to the absolute URL (which requires checking
for the base URL in the HEAD), which may or may not be acceptable.

> Google has some strange html, href without quotation marks:  href=http://www.google.com/ncr>Google.com in English

That's not strange. That's just a bit unusual. Perfectly legal, though
- any browser (or other html processor) that fails to handle it is
broken.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Parsing an HTML a tag

[Mike Meyer]

"beza1e1" <[EMAIL PROTECTED]> writes:

> I think for a quick hack, this is as good as a parser. A simple parser
> would miss some cases as well. RE are nearly not extendable though, so
> your critic is valid.

Pretty much any first attempt is going to miss some cases. There
libraries available that are have stood the test of time. Simply
usinng one of those is the right solution.

> The point is, what George wants to do. A mixture would be possible as
> well:
> Getting all  by a RE and then extracting the url with something
> like a parser.

I thought the point was to extract all URLs? Those appear in
attributes of tags other than A tags. While that's a meta-problem that
requires properly configuring the parser to deal with, it's something
that's *much* simpler to do if you've got a parser that understands
the structure of HTML - you should be able to specify tag/attribute
pairs to look for - than with something that is treating it as
unstructured text.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ncurses programming

[Mike Meyer]

Torsten Bronger <[EMAIL PROTECTED]> writes:

> Hallöchen!
>
> "ncf" <[EMAIL PROTECTED]> writes:
>
>> [...]
>>
>> Py Docs:   http://docs.python.org/lib/module-curses.html
>
> This document suggests that Python+ncurses won't work on windows.
> What's the reason for this?

Could it be that ncurses doesn't work on Windows? At least, it didn't
last time  I looked. There was a curses library for Windows, but
you'll have to google for it.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: attribute error

[Mike Meyer]

"M.N.A.Smadi" <[EMAIL PROTECTED]> writes:

> HI;
>
> I am  having the following error.  I am using someone else's code and
> all they are doing is pass an argv to a function then
>
> def execute_action(manager, argv):
> method_name = argv.pop(0).lower()
>
>
> and am getting this strange error.
> AttributeError: 'str' object has no attribute 'pop'
>
> am using Python 2.3.4 and am importing the following libraries:
>
> import sys, os, inspect
> from Asterisk import Manager, BaseException, Config
> import Asterisk.Util
>
> but i always thought that something like this will be standard stuff.
> Any ideas?

Yes - show us the rest of the code. execute_action is never called in
the snippets you posted, and it's pretty clear that it's being invoked
with the wrong thing as an argument. Can you provide a minimal working
(well, executable) code sample that generates the error message you
are getting?

Oh yeah - post the full traceback as well.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 350: Codetags

[Tony Meyer]

On 27/09/2005, at 12:21 PM, Paul Rubin wrote:

> Neil Hodgson <[EMAIL PROTECTED]> writes:
>
>> The PEP system allows for the documentation of a convention as an
>> "Informational PEP". Documenting conventions is useful.
>
> If the preferred method of doing something is
> consistent enough that it can be codified as a convention in a PEP, it
> should be implemented in the compiler, so it becomes a language
> feature, not a convention.

Does this mean that you think that PEP 8 (Python Code Style Guide)  
should be enforced by the compiler?  So that (e.g) lines that are too  
long just don't compile?

I really doubt you'll find much agreement for this (the compiler  
should enforce it) position.  The 'fewer conventions are better'  
position might enjoy more support, but doesn't strike me as  
particularly Pythonic (e.g. compare whitespace in Python and C).

=Tony.Meyer

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

Re: Overhead of individual python apps

[Mike Meyer]

"Qopit" <[EMAIL PROTECTED]> writes:

> When running in Windows, launching each application generates a
> process, and each of those processes ends up taking up > 4MB of system
> memory.  This memory usage is as reported by the Windows Task manager
> for the python.exe image name.

The first step is to clarify what's being reported. If WTM is
reporting the total memory usage for each process, then it's over
estimating the total usage by a considerable amount. In particular,
all the Python executable code should be shared by all the
processes. Unless you load compiled extensions, anyway - those will
only be shared by the ones that use them. You'll need something that
will give you the stack, heap and code segment sizes separately to
work out what the memory usage really is.

> My Question: Is there any way to reduce this per-process overhead?  eg:
> can you set it somehow so that one python.exe instance handles multiple
> processes?

The OS should do that for you by default.

> One possibility considered is to run them as threads of a single
> process rather than multiple processes, but this has other drawbacks
> for my application and I'd rather not,

That shouldn't help memory usage - the data that isn't across
processes would need to be thread-private in any case.

The reason for the uncertainty is that I'm not positive that Windows
behaves sanely in this area. It may be that Windows doesn't have
shared executables. In this case, one solution is to move to a modern
OS - like v6 Unix :-).

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Human readable number formatting

[Mike Meyer]

Alex Willmer <[EMAIL PROTECTED]> writes:

> When reporting file sizes to the user, it's nice to print '16.1 MB',
> rather than '16123270 B'. This is the behaviour the command 'df -h'
> implements. There's no python function that I could find to perform this
> formatting , so I've taken a stab at it:
>
> import math
> def human_readable(n, suffix='B', places=2):
> '''Return a human friendly approximation of n, using SI prefixes'''
> prefixes = ['','k','M','G','T']
> base, step, limit = 10, 3, 100
> 
> if n == 0:
> magnitude = 0 #cannot take log(0)
> else:
> magnitude = math.log(n, base)
> 
> order = int(round(magnitude)) // step
> return '%.1f %s%s' % (float(n)/base**(order*step), \
>   prefixes[order], suffix)
>
> Example usage
 print [human_readable(x) for x in [0, 1, 23.5, 100, 1000/3, 500,
> 100, 12.345e9]]
> ['0.0 B', '1.0 B', '23.5 B', '100.0 B', '0.3 kB', '0.5 kB', '1.0 MB',
> '12.3 GB']
>
> I'd hoped to generalise this to base 2 (eg human_readable(1024, base=2)
> == '1 KiB' and enforcing of 3 digits at most (ie human_readable(100) ==
> '0.1 KB' instead of '100 B). However I can't get the right results
> adapting the above code.
>
> Here's where I'd like to ask for your help.
> Am I chasing the right target, in basing my function on log()?

I wouldn't have done it that way, but that's not worth very much. Can
you use the log() variation to change form proper scientific units
to the CS powers-of-two variation?

if not, I would do it this way:

def human_readable(n, suffix = 'B', places = 2):
prefixes = ['', 'K', 'M', 'G', 'T', 'P', 'E']

top = 10 ** places
index = 0
n = float(n)
while abs(n) > top:
  n /= 10
  index += 1
return '%.1f %s%s' % (n, prefixes[index], suffix)

> Does this function already exist in some python module?

humanize_number is a cross-platform C library function, about 150
lines of code. It uses the loop I gave above. It might be worthwhile
to swipe the code (it's BSD-licensed), wrap it, and submit a PR to add
it to the standard library - just so you get properly tested code.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Tony Meyer]

On 28/09/2005, at 11:05 PM, Simon Brunning wrote:

> On 9/28/05, could ildg <[EMAIL PROTECTED]> wrote:
>
>> Python is wonderful except that it has no real private and protected
>> properties and methods.
>> Every py object has dict so that you can easily find what fields  
>> and methods
>> an obj has, this is very convenient, but because of this, py is  
>> very hard
>> to support real private and protected?
>
> My convention, attributes with names prefixed with a single underscore
> are private. There's nothing to stop anyone using these, but, well, if
> you take the back off the radio, the warranty is void.

I'm not sure why I haven't seen this mentioned yet, but a leading  
double-underscore does really make a member private:

 >>> class f(object):
...   def __init__(self):
... self.__f = 1
...
 >>> a = f()
 >>> a.__f
Traceback (most recent call last):
   File "", line 1, in ?
AttributeError: 'f' object has no attribute '__f'
 >>> dir(a)
['__class__', '__delattr__', '__dict__', '__doc__',  
'__getattribute__', '__hash__', '__init__', '__module__', '__new__',  
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__',  
'__weakref__', '_f__f']

As you see, it's there in the dict, but it's obfuscated - but that's  
all that other languages do anyway.  Anyone that takes advantage of  
that to get hold of members like this should have a very good reason  
for doing so.

Just think of a single leading underscore as protected, and double  
leading underscores as private, and you'll be fine.  As Simon said,  
people can still access these, but the consenting adults rule applies.

=Tony.Meyer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Tony Meyer]

On 28/09/2005, at 11:54 PM, Paul Rubin wrote:

> Tony Meyer <[EMAIL PROTECTED]> writes:
>
>> I'm not sure why I haven't seen this mentioned yet, but a leading
>> double-underscore does really make a member private:...
>> As you see, it's there in the dict, but it's obfuscated - but that's
>> all that other languages do anyway.
>>
>
> No, that's false: [snip]

I didn't say *all* other languages, and I meant many other languages,  
although that's not clear from what I wrote.

=Tony.Meyer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Tony Meyer]

On 28/09/2005, at 11:55 PM, Simon Brunning wrote:

> On 9/28/05, Tony Meyer <[EMAIL PROTECTED]> wrote:
>
>> I'm not sure why I haven't seen this mentioned yet, but a leading
>> double-underscore does really make a member private:
>>
>
> I thought about it, but I didn't mention it in the end because this
> feature ("name mangling") isn't intended as a mechanism for making
> things private - it's intended to prevent namespace clashes when doing
> multiple inheritance.

That's not what the documentation says:

"""
9.6 Private Variables

There is limited support for class-private identifiers.
[...]
Name mangling is intended to give classes an easy way to define  
``private'' instance variables and methods,
[...]
"""

<http://docs.python.org/tut/node11.html>

=Tony.Meyer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin  writes:

> Chris Gonnerman <[EMAIL PROTECTED]> writes:
>> -- Make it easy to do right.
>> 
>> What you are promoting is the first philosophy: Tie the programmer's
>> hands so he can't do wrong.  Python for the most part follows the
>> second philosophy, making writing good code so easy that the coder
>> is rarely tempted to commit any evil.
>
> Unless you can show that all Python code is bug-free, you've got to
> consider that there might be something to this private and protected
> stuff.  See for example this message:
>
>   http://groups.google.com/group/sci.crypt/msg/59516419dc874e63?dmode=source
>
> Name mangling is a poor substitute for private variables.  If you want
> to be able to share private variables with other classes under certain
> circumstances, it's better to use something like C++'s "friend"
> declaration, where you can export the variables to a specific other class.

Note that the quoted article only applies to *writing* attributes. It
doesn't say anything about needing accessors to *read* a
variable. This encourages me that the convention I use - adopted from
Eiffel, where the compiler enforces it - of freeling reading
attributes, but providing methods to write them - is a right way todo
things.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin  writes:

> Gregor Horvath <[EMAIL PROTECTED]> writes:
>> > to be able to share private variables with other classes under certain
>> > circumstances, it's better to use something like C++'s "friend"
>> > declaration, where you can export the variables to a specific other class.
>> 
>> That assumes that you always know for sure that the given variable
>> will always be used as a private/friend variable in the lifecycle of
>> the software.
>
> Obviously if you find you need to use it in another place later, you
> update the declaration.  The idea is for you (or an automatic tool) to
> be able to find all the uses of some instance variable.  In Python
> (because of things like setattr), that can't be done.

One of the advantages of avoiding boilerplate is that you avoid the
need to maintain it.

It's not clear that tracking all uses of a variable in Python can't be
done. It's clear that it's *difficult* - you have to track the objects
bound to both arguments for ever setattr call - but that's not the
same thing as impossible. My gut says "halting problem", but I haven't
proved it. Most other languages aren't that different - unless you
place serious restrictions on them. For instance, most languages will
let me pass a reference to an instance variable to a method of another
object. If that method then stores the reference in a global (or
class, or instance) variable, you suddenly have to track the value of
that new variable to figure out if the variable of interest is being
used whenever the new one is used. Which is pretty much the same place
you get with setattr.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> Note that the quoted article only applies to *writing* attributes. It
>> doesn't say anything about needing accessors to *read* a
>> variable. This encourages me that the convention I use - adopted from
>> Eiffel, where the compiler enforces it - of freeling reading
>> attributes, but providing methods to write them - is a right way todo
>> things.
>
> Generally that sounds reasonable.  Obviously there are other examples
> when (e.g. for security) you have to make sure that variables can't be
> read by other classes, e.g. you have a class that stores a capability
> (or a password) in an instance variable, and uses it for privileged
> operations.  

If you can't trust the code that shares your address space, you're in
a world of hurt for security. Compile-time restrictions don't matter
for squat - you need serious restrictions on what the program can do
at runtime.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Tony Meyer]

On 29/09/2005, at 3:45 AM, Fredrik Lundh wrote:

> Tony Meyer wrote:
>
>>> I thought about it, but I didn't mention it in the end because this
>>> feature ("name mangling") isn't intended as a mechanism for making
>>> things private - it's intended to prevent namespace clashes when  
>>> doing
>>> multiple inheritance.
>>
>> There is limited support for class-private identifiers.
>> [...]
>> Name mangling is intended to give classes an easy way to define
>> ``private'' instance variables and methods,
>> [...]
>> """
>
> the sentence you're quoting the first part of continues:
>
> without having to worry about instance variables defined by  
> derived
> classes

That elaborates on the intent, it doesn't change it.  The sentence  
clearly says that the intent is to easily define private variables,  
whereas Simon said that it the intent was not to provide a mechanism  
for making variables private.

> and the paragraph later says:
>
> Note that the mangling rules are designed mostly to avoid  
> accidents

That's explaining why you can still access the variables if you want  
to, not saying that this feature isn't meant to be used to indicate  
that a variable is private.

> and both sentences are from the *tutorial*, which doesn't exactly
> qualify as a design document.

A tutorial should not encourage users to use a feature in the wrong  
way, though.  If leading underscore(s) were not meant to indicate  
privateness, then the tutorial should not state that - this is where  
a large proportion of users learn Python; it's nonsensical to teach  
them something that's incorrect.

> if you want more rationale, here's the
> post that led to the current design:
>
> http://groups.google.com/group/comp.lang.python/msg/e79f875059d9a2ba
>
> "In my version, private data has it's own scope, so that name  
> clashes
> will not occur if a private with the same name is used in a  
> subclass."
>
> see the rest of that thread for more about the history of __.

Disagreeing with someone who actually took part in the discussion may  
not be a sensible idea but...

It's pretty clear to me from that thread that using a single/double  
underscore with variables *is* intended to indicate that the variable  
is private in some fashion.  As Guido pointed out:

 '*leading* underscore has a long tradition (in the C world,
 anyway, but we don't really want to ignore that here) of meaning
 "internal use" (of some kind)'

<http://groups.google.com/group/comp.lang.python/msg/edecfde2141f642b>

The name mangling lets one use private variables without having to  
worry about name clashes, but the purpose of the leading underscore 
(s) is to indicate that the variable is private

 "private seems to be useful because it offers a form of data
 hiding that's currently absent in Python"

<http://groups.google.com/group/comp.lang.python/msg/593533b57662438f>

as many people in that thread indicated that they were doing before  
this was proposed as an addition.

The OP wanted to know how to use private (and protected) variables in  
Python.  Even the FAQ has this answer:

 'Variables with double leading underscore are "mangled" to provide
 a simple but effective way to define class private variables.
 [...]
 This doesn't guarantee privacy: an outside user can still  
deliberately
 access the "_classname__spam" attribute, and private values are  
visible
 in the object's __dict__."

<http://www.python.org/doc/faq/programming.html#i-try-to-use-spam-and- 
i-get-an-error-about-someclassname-spam>

Which is basically what I said in my reply to the OP.  If this isn't  
the intent, then there's a lot of incorrect documentation, and a lot  
of incorrect c.l.p answers to this question in the past*.

=Tony.Meyer

* Well, there are no doubt a lot of incorrect c.l.p answers to any  
question :).  But anyway...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> > Generally that sounds reasonable.  Obviously there are other examples
>> > when (e.g. for security) you have to make sure that variables can't be
>> > read by other classes, e.g. you have a class that stores a capability
>> > (or a password) in an instance variable, and uses it for privileged
>> > operations.  
>> 
>> If you can't trust the code that shares your address space, you're in
>> a world of hurt for security. Compile-time restrictions don't matter
>> for squat - you need serious restrictions on what the program can do
>> at runtime.
>
> You need both.

Yup. Any language besides Java even *try* to provide both for a
production environment? Lots of languages do runtime checking that can
be disabled for production compilation - which makes it's worthless in
this case.

Of course, at this point you're no longer talking about a general
purpose programming environment. Language design decisions that are
correct for this environment aren't necessarily correct for general
purpose programming languages. Trying to tweak some exiting general
purpose language to make it suitable for use in the kind of
environment where you can't trust the code you share your address
space with is the wrong way to go about it. You want to design such a
language to fit your secure environment, *after* you've designed that
environment.

At that point, things which are unrelated to the security of the
environment may be more attractive than they would be in a general
purpose programming language. A number of runtime checks have to be in
place to insure that semantics of the language stay "correct". Since
we're going to have those, I would like constructs I can use to ensure
that the semantics of the program stay correct, like function
entry/exit conditions, loop and object invariants, and so
on. Basically, the whole DbC thing.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A quick c.l.p netiquette question

[Mike Meyer]

Steve Holden <[EMAIL PROTECTED]> writes:
>> I think you missed the other Peter's second post, where he points to
>> his
>> program: http://www.pick.ucam.org/~ptc24/yvfc.html
>> I didn't read every one of his 158 lines, but his code is pure
>> poetry, or
>> possibly triple-distilled evil, depending on your point of view.  158 lines
>> very well spent either way!

SIOD in Python. Sort of.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: attribute error

[Mike Meyer]

In <[EMAIL PROTECTED]>, M.N.A.Smadi <[EMAIL PROTECTED]> typed:
> HI;
> 
> I am  having the following error:
> 
> AttributeError: 'str' object has no attribute 'pop'
> 
> am using Python 2.3.4 and am importing the following libraries:
> 
> import sys, os, inspect
> from Asterisk import Manager, BaseException, Config
> import Asterisk.Util
> 
> The code being executed is:
> if command not in commands:
> raise ArgumentsError('invalid arguments.')
> 
> 
> 
> if command == 'usage':
> return usage(argv[0], sys.stdout)
> 
> manager = Manager.Manager(*Config.Config().get_connection())
> 
> if command == 'actions':
> show_actions()
> 
> if command == 'help':
> if len(argv) < 3:
> raise ArgumentsError('please specify an action.')
> 
> show_actions(argv[2])
> 
> elif command == 'action':
> if len(argv) < 3:
> raise ArgumentsError('please specify an action.')
> 
> try:
> execute_action(manager, argv[2:])
> except TypeError, e:
> print "Bad arguments specified. Help for %s:" % (argv[2],)
> show_actions(argv[2])
> 
> elif command == 'command':
> execute_action('command', argv[2])

This should be execute_action('command', argv[2:]), with the ':' added.

 def execute_action(manager, argv):
> method_name = argv.pop(0).lower()
> 
> 
> 
> but i always thought that something like this will be standard stuff.
> Any ideas?
> 
> 
> Mike Meyer wrote:
> 
> >"M.N.A.Smadi" <[EMAIL PROTECTED]> writes:
> >
> >  
> >
> >>HI;
> >>
> >>I am  having the following error.  I am using someone else's code and
> >>all they are doing is pass an argv to a function then
> >>
> >>def execute_action(manager, argv):
> >>method_name = argv.pop(0).lower()
> >>
> >>
> >>and am getting this strange error.
> >>AttributeError: 'str' object has no attribute 'pop'
> >>
> >>am using Python 2.3.4 and am importing the following libraries:
> >>
> >>import sys, os, inspect
> >>from Asterisk import Manager, BaseException, Config
> >>import Asterisk.Util
> >>
> >>but i always thought that something like this will be standard stuff.
> >>Any ideas?
> >>
> >>
> >
> >Yes - show us the rest of the code. execute_action is never called in
> >the snippets you posted, and it's pretty clear that it's being invoked
> >with the wrong thing as an argument. Can you provide a minimal working
> >(well, executable) code sample that generates the error message you
> >are getting?
> >
> >Oh yeah - post the full traceback as well.
> >
> > >
> >  
> >
> 
> 

-- 
Mike Meyer <[EMAIL PROTECTED]>  http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: attribute error

[Mike Meyer]

In <[EMAIL PROTECTED]>, M.N.A.Smadi <[EMAIL PROTECTED]> typed:
> This has nothing to do with how the argument is passed.  It is prob 
> something wrong with str.pop in my python because when i run python and type
> import os
> import string
> x = '1 2 3'
> x.pop()
> 
> i get the following error
> Traceback (most recent call last):
>   File "", line 1, in ?
> AttributeError: 'str' object has no attribute 'pop'

The only thing wrong with str.pop is that you're trying to invoke
it. The interpreter is telling you that string doesn't *have* a pop
method. The interpreter is right. Strings are immutable, so "pop"
doesn't make any sense for them.

 
> Mike Meyer wrote:
> 
> >In <[EMAIL PROTECTED]>, M.N.A.Smadi <[EMAIL PROTECTED]> typed:
> >  
> >
> >>HI;
> >>
> >>I am  having the following error:
> >>
> >>AttributeError: 'str' object has no attribute 'pop'
> >>
> >>am using Python 2.3.4 and am importing the following libraries:
> >>
> >>import sys, os, inspect
> >>from Asterisk import Manager, BaseException, Config
> >>import Asterisk.Util
> >>
> >>The code being executed is:
> >>if command not in commands:
> >>raise ArgumentsError('invalid arguments.')
> >>
> >>
> >>
> >>if command == 'usage':
> >>return usage(argv[0], sys.stdout)
> >>
> >>manager = Manager.Manager(*Config.Config().get_connection())
> >>
> >>if command == 'actions':
> >>show_actions()
> >>
> >>if command == 'help':
> >>if len(argv) < 3:
> >>raise ArgumentsError('please specify an action.')
> >>
> >>show_actions(argv[2])
> >>
> >>elif command == 'action':
> >>if len(argv) < 3:
> >>raise ArgumentsError('please specify an action.')
> >>
> >>try:
> >>execute_action(manager, argv[2:])
> >>except TypeError, e:
> >>print "Bad arguments specified. Help for %s:" % (argv[2],)
> >>show_actions(argv[2])
> >>
> >>elif command == 'command':
> >>execute_action('command', argv[2])
> >>
> >>
> >
> >This should be execute_action('command', argv[2:]), with the ':' added.
> >
> >  >
> >  
> >
> >>def execute_action(manager, argv):
> >>method_name = argv.pop(0).lower()
> >>
> >>
> >>
> >>but i always thought that something like this will be standard stuff.
> >>Any ideas?
> >>
> >>
> >>Mike Meyer wrote:
> >>
> >>
> >>
> >>>"M.N.A.Smadi" <[EMAIL PROTECTED]> writes:
> >>>
> >>> 
> >>>
> >>>  
> >>>
> >>>>HI;
> >>>>
> >>>>I am  having the following error.  I am using someone else's code and
> >>>>all they are doing is pass an argv to a function then
> >>>>
> >>>>def execute_action(manager, argv):
> >>>>   method_name = argv.pop(0).lower()
> >>>>
> >>>>
> >>>>and am getting this strange error.
> >>>>AttributeError: 'str' object has no attribute 'pop'
> >>>>
> >>>>am using Python 2.3.4 and am importing the following libraries:
> >>>>
> >>>>import sys, os, inspect
> >>>>
> >>>>
> >>>>from Asterisk import Manager, BaseException, Config
> >>>  
> >>>
> >>>>import Asterisk.Util
> >>>>
> >>>>but i always thought that something like this will be standard stuff.
> >>>>Any ideas?
> >>>>   
> >>>>
> >>>>
> >>>>
> >>>Yes - show us the rest of the code. execute_action is never called in
> >>>the snippets you posted, and it's pretty clear that it's being invoked
> >>>with the wrong thing as an argument. Can you provide a minimal working
> >>>(well, executable) code sample that generates the error message you
> >>>are getting?
> >>>
> >>>Oh yeah - post the full traceback as well.
> >>>
> >>>>>>
> >>> 
> >>>
> >>>  
> >>>
> >>
> >>
> >
> >  
> >
> 
> 

-- 
Mike Meyer <[EMAIL PROTECTED]>  http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin  writes:
> Bill Mill <[EMAIL PROTECTED]> writes:
>> Python is for consenting adults.
>
> Python might be for consenting adults, but multi-person software
> projects are supposed to be done in the workplace, not the bedroom.
> So there are still some software constructs that are simply beyond the
> bounds of propriety, and I think we're discussing one of them. ;-).

Bondage and discipline - even between consenting adults - is *usually*
considered beyond the bounds of propriety. Since that's what's being
discussed, I'd say "yup."

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A Moronicity of Guido van Rossum

[Tony Meyer]

On 30/09/2005, at 9:50 AM, Delaney, Timothy (Tim) wrote:

> You have to admit though, he's remarkably good at getting past
> Spambayes. Despite classifying *every* Xah Lee post as spam, he still
> manages to get most of his posts classified as 0% or 1% spam.

I can't believe that people are using c.l.p trolls as justification  
in their push to add white/black-listing to spambayes now .

I expect that if you look at the clues for such messages, you'll find  
that any 'Xah Lee' clues are swamped by lots of 'c.l.p message'  
clues.  A big problem with filtering mailing lists at the user end  
(rather than before the post is accepted) is that the mailing  
software adds so many strongly-correlated clues.  It's made worse  
because he uses so many words that you'd expect to find in legitimate  
c.l.p messages.

To fight this sort of message, I think spambayes would have to be  
able to understand the context more.

=Tony.Meyer

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

Re: A Moronicity of Guido van Rossum

[Tony Meyer]

> I know nobody wants to do add "white/black-listing", so we can do it
> probabilistically. In case it is not obvious, mailings with the words
> "jargon" or "moron" and their derrivatives should be flagged as 99.9%
> probability for Moronicity Xha Lee, Jargonizer, spam. If spam bayes  
> can't
> figure this out, then either it is not properly implemented or  
> Bayes himself
> was out to lunch.

I knew I'd regret my response .

The problem here isn't getting an appropriately spammy score for  
particular tokens, like Xah's name.  The problem is that the  
classifier has to taken into account the entire message, and the  
hammy clues outweigh the spammy ones (not unexpected, really,  
considering that other than all the trolling, the messages are  
reasonably on-topic).

This is a feature, not a bug.  It's the same feature that means that  
messages talking about spam on the spambayes mailing list, or the  
legitimate mail I get about viagra , get through to me.

=Tony.Meyer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin  writes:
> OTOH, "private" lets you say 100% for certain that another class
> didn't clobber __xyz, and that any bug that clobbered it MUST reside
> in the class that declared it.  That makes auditing for __xyz-related
> errors a lot simpler since you only have to look in one class for them.

Horse pucky.

>>> class Fools(object):
... _bar = "my private list of values".split()
... def broken(self, breaker):
... breaker(self._bar)
... 
>>> class Kings(object):
[Elided, because you said you don't need it.]
>>> fool = Fools()
>>> king = Kings()
>>> fool.broken(king.get_victim)
>>> king.breakit()
>>> fool._bar
[]
>>> 

So, fool._bar is now clobbered. Nuts, the _bar attribute is broken for
*every* instance of Fools. According to you, the error must be in
Fools. Care to point it out?

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hello gnome-terminal

[Mike Meyer]

egbert <[EMAIL PROTECTED]> writes:

> When I start the following script in a gnome-terminal:
>
> #!/usr/bin/env python
> import os
> print "hello gnome-terminal"
> print os.environ["PYTHONPATH"]
> 
> I see the expected results in the same gnome-terminal window.
>
> However starting this same script via a launcher in a panel,
> a new gnome-terminal window is opened for output only,
> and PYTHONPATH is an unknown entity.
> How can I open a terminal over whose environment and

X has been breaking environments this way for decades. You have two
choices:

1) Tell gnome-terminal that it needs to start a login shell, assuming
   you can.

2) Move the setting of PYTHONPATH into a different startup file, one
   that will be executed by all shells when they start.

Whatever you do, don't ask about .MacOSX/preferences.plist.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Google Not Universal Panacea

[Mike Meyer]

Steve Holden <[EMAIL PROTECTED]> writes:
> However,
>
>  >> Are people really too lazy to do elementary research on Google?
>
> goes a bit too far in imputing motives to the enquirer and overlooking
> the fact that there are some very good reasons for *not* using Google.

Ok, *what* are the reasons for not using Google?

I agree with Steve - there's no reason to impugn the motives of
someone looking for answers. They may not realize what an excellent
resource Google is. People have to learn how to find answers, just
like they have to learn how to use Python. Suggesting that they check
Google - if they didn't say they already did - is perfectly
reasonable. Assuming they are to lazy to do so is something else
again.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: where to post python code?

[Mike Meyer]

Alessandro Bottoni <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
>
>> the question it - where should i post the code to?
>> It's not big enough to justify a source forge project, nor is it small
>> enough to be considered a receipt fit for ASPN's Python Cookbook.
>
> Maybe "The Vaults of Parnassus" at www.vex.net is the right place for it.

Don't forget to add an entry to PyPI as well.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A Moronicity of Guido van Rossum

[Mike Meyer]

Steve Holden <[EMAIL PROTECTED]> writes:

> [off-list]
>
> Peter Hansen wrote:
>> Gerrit Holl wrote:
>>
>>>True. However, most mail to this mailinglist has less than 0.001 spam
>>>probability. As you can see, this one had 0.048 - a vast score, almost
>>>enough to put it in my unsure box. It seems to be just not hammy enough.
>>>It's interesting to see that no none of the foul language words used by
>>>Xah Lee ever occurs in any spam I receive - spam is not that stupid.
>> "Xah Lee: stupider than spam." (?)
>> -neologism-intentional-ly y'rs,
>>   Peter
> I'm responding off-list so's not to give this loony's threads any more
> visibility.

You seem to have goofed.

> FWIW I really like the slogan. Maybe you should register
> "stupiderthanspam.com" and make a million? Amused me no end.

I smell a google bomb. Add the link "http://xahlee.org/";>stupider than spam" to your favorite web
page, and in a while typing "stupider than spam" into google and
hitting "I feel lucky" will take you to Xah Lee's home page

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:

> Mike Meyer <[EMAIL PROTECTED]> writes:
>> So, fool._bar is now clobbered. Nuts, the _bar attribute is broken for
>> *every* instance of Fools. According to you, the error must be in
>> Fools. Care to point it out?
>
> Yes, the error is in the "breaker" function, which leaks the private
> variable to other classes,

Wrong. The bug is in the King class, which is clobbering objects it's
not supposed to clobber.

Unless your compiler detects and flags passing private variables to
external functions all you've got is a convention that you don't pass
private variables to external functions.

> This is the kind of thing that you'd look for in an audit, so I
> don't see your point.

So would you audit catch this one:

class Fools(object):
... _foo = "my private list of values".split()
... def broken(self):
... return len(self._foo)
... 
>>> fool = Fools()
>>> fool.broken()
>>> fool._foo
[]

Are you going to try and tell me thas using builtin functions on
private variables is something you don't allow in your projects?

If all you've got is a convention for some of the cases you're trying
to catch, then having a compiler enforce private variables isn't
fundamentally different from having a convention that you don't touch
variables with specific names. It lets the comiler catch more bugs,
but doesn't mean that such bugs are suddenly impossible.

Of course, there's nothing wrong with catching errors earlier. Might I
suggest that you file a change request for pylint (or your favorite
error checker) asking that it start issuing warnings for
object._variable?

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A Moronicity of Guido van Rossum

[Tony Meyer]

On 30/09/2005, at 10:56 PM, Gerrit Holl wrote:

> Tony Meyer wrote:
>
>> X-Spambayes-Classification: ham; 0.048
>> X-Spambayes-Evidence: '*H*': 0.90; '*S*': 0.00; 'bug.': 0.07;  
>> 'flagged': 0.07;
>> "i'd": 0.08; 'bayes': 0.09; 'from:addr:ihug.co.nz': 0.09;
>> 'really,': 0.09; 'cc:no real name:2**0': 0.14;
>> 'from:addr:t-meyer': 0.16; 'from:name:tony meyer': 0.16;
>> 'obvious,': 0.16; 'spambayes': 0.16; 'subject:Guido': 0.16;
>> 'trolling,': 0.16; 'regret': 0.82; 'lee,': 0.91; 'viagra': 0.91;
>> 'mailings': 0.93; 'probability': 0.93
>
>> This is a feature, not a bug.  It's the same feature that means that
>> messages talking about spam on the spambayes mailing list, or the
>> legitimate mail I get about viagra , get through to me.
>>
>
> True. However, most mail to this mailinglist has less than 0.001 spam
> probability. As you can see, this one had 0.048 - a vast score, almost
> enough to put it in my unsure box. It seems to be just not hammy  
> enough.
> It's interesting to see that no none of the foul language words  
> used by
> Xah Lee ever occurs in any spam I receive - spam is not that stupid.

Unless I'm misreading things, that's *my* message that scored 0.048  
(the "from:addr:ihug.co.nz", "from:name:tony meyer", and "spambayes"  
tokens make it seem that way)...

=Tony.Meyer

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

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:

> Mike Meyer <[EMAIL PROTECTED]> writes:
>> Unless your compiler detects and flags passing private variables to
>> external functions all you've got is a convention that you don't pass
>> private variables to external functions.
> Yes, the point is that it's something that you can check for by
> examining the class in question without having to examine any other
> classes.

That's a pretty restrictive convention to follow. For instance, I
might want an error dialog to be a private variable of a class
representing a window - after all, I don't want anyone else writing to
it, or using it in any way. Except, of course, for any GUI framework
routines I have to pass it to in order to use it. This problem crops
up for every utility routine in every library I might want to
use. Opening files by name, concatenatting strings (or are we going to
have a convention that implicit invocation of functions with the
operator syntax don't count, and another one that you don't overload
operators with destructive functions, and so on), etc.

So it turns out that getting the behavior you desire involves
following a lot of conventions.

>> I you going to try and tell me thas using builtin functions on
>> private variables is something you don't allow in your projects?
>
> You have to treat builtin functions as part of the language.  Of
> course Python has this situation where someone could rebind the name
> "len" to some other function, so you have to deal with that too, maybe
> just at the file scope.

File scope isn't good enough for python.

import madhouse
madhouse.len = my_len_breaker
fool = madhouse.Fool()
print fool.break()

and fool._foo is broken again.

> An OOP approach (lst.len() instead of len(lst)) that binds the
> builtin names to datatypes might be preferable in some situations
> but I'll leave that one for the theorists.

In other words, to get this to work the way you want, you need yet
another convention - this one being about how one goes about writing
utility functions. It may be that you can design a language and
support libraries so that the compiler can enforce all your
conventions. There are languages that try to do that. I recall one I
ran into in the 70s that distinguished between "functions" (which
returned values) and "procedures" (which had side effects), and the
compiler enforced (or tried to) the distinction. I think you'd need
something like that.

But that isn't what we've got. What we've got is Python. Which means
you need a whole boatload of conventions to make this work the way you
want.

In other words, by adding private to python, you're making it so that
bugs involving overwriting a private attribute will involve only the
owning classes code so long as everyone follows the conventions that
exist about the use of such variables.

This should be contrasted with the current situation, where bugs that
involve overwriting an _-prefixed attribute will involve only the
owning classes code so long as everyone follows the conventions that
exist about the use of such variables.

Yeah, I guess private makes things a lot better.

>> Of course, there's nothing wrong with catching errors earlier. Might I
>> suggest that you file a change request for pylint (or your favorite
>> error checker) asking that it start issuing warnings for
>> object._variable?
>
> I don't see how pylint could know which instances to flag, without
> doing type inference on all the objects to know that the variable
> belonged to an instance of some other class.

I was thinking it would flag any use of such a variable where the
target variable wasn't "self". That may be a stronger constraint than
you wanted - but that's good, right?

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: Phases of the moon

[Mike Meyer]

Bart Lateur <[EMAIL PROTECTED]> writes:

> Steven D'Aprano wrote:
>
>>A skeptical policeman who says he doesn't actually believe the moon
>>affects behaviour nevertheless reports that "last weekend" things were
>>really crazy, and it was a full moon. Somebody writes in to correct him:
>>no, the full moon is actually "tomorrow".
>
> As a similar example: I've been told by various women independently,
> that "there are more babies born near a full moon."
>
> So... is there a correlation between insanity and babies being born?  :)

If what they say is true, then yes, there is. That doesn't mean
there's a logical - or even rational - explanation for that
correlation.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> > Yes, the point is that it's something that you can check for by
>> > examining the class in question without having to examine any other
>> > classes.
>> 
>> That's a pretty restrictive convention to follow.
>
> What convention?  It just makes it possible to write code with some
> specific invariants if there's a need to do so.

That you don't pass private variables to a function unless it's a
buitin. Python is *not* a strict OO language, and uses utility
functions for lots of things. To make private work the way you have to
change the library to use a strict OO approach, probably including
providing a real hierarchy instead of just duck typing.

>> So it turns out that getting the behavior you desire involves
>> following a lot of conventions.
>
> That improves on the current situation.  Right now the behavior is
> impossible to obtain in Python no matter how many conventions you
> follow, unless you follow them through a whole program of arbitrary
> size instead of just in the class that you're trying to protect a
> variable in. 

Just adding private doesn't change this significantly - it just makes
the compiler enforce one of the large number of conventions you have
to follow.

>> In other words, by adding private to python, you're making it so that
>> bugs involving overwriting a private attribute will involve only the
>> owning classes code so long as everyone follows the conventions that
>> exist about the use of such variables.
> Not everyone, just the author of the class that uses the private
> variable.  That's the point.

Except that, with Python as it exists today with a private keyword
added, it's *still* everyone. The only convention breaking the private
keyword would allow the compiler to catch is a reference to
foo.private. It wouldn't catch overriding things in __builtins__ or
overriding builtins in a module, or things poking at the variable
through __dict__, or - well, there are probably lots of things that
need to be dealt with.

>> > I don't see how pylint could know which instances to flag,
>> I was thinking it would flag any use of such a variable where the
>> target variable wasn't "self". That may be a stronger constraint than
>> you wanted - but that's good, right?
> Shrug.  That might be of some limited usefulness, but all it tries to
> do is prevent accidents.  And it does nothing about setattr/getattr.

Preventing accidents is all "private" does - without fundamental
changes to the implementation of the language. You have to catch every
mechanism that can be used to find a reference to an attribute, like
references to __dict__ and to the class variable.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Well, it's a discussion of why a certain feature might be useful, not
> that it's required.  Mike Meyer points out some reasons it might be
> hard to do smoothly without changing Python semantics in a deep way
> (i.e. Python 3.0 or later).  

Actually, I think that the semantic changes required to make private
do what you want are deep enough that the resulting language wouldn't
be Python any longer. It has deep implications from the interpeter
implementation all the way out to the design of the standard library,
all of which would have to be reworked to make private do "the right
thing."

Not that I think that private is a bad idea. If I'm not writing
python, then I'm probably writing Eiffel. Eiffel has facilities for
protecting features, though the design is more consistent than the
mishmash one gets in C++/Java. Nuts - in Eiffel, you can't write
"instance.attribute = value"; assignment to an attribute has to be
done in a method of the owning instance.

Which brings me to my point. Rather than trying to bandage Python to
do what you want - and what, based on this thread, a lot of other
people *don't* want - you should be building a system from the ground
up to support the kind of B&D environment you want.

Of course, you do realize that in practice you can *never* get what
you want. It assumes that the infrastructure is all bug-free, which
may not be the case.

For example, I once had a system that took a kernel panic trying to
boot an OS upgrade. It had been running the previous versionn of the
OS for most of a year with no problems. Other basically identical
systems ran the upgraded OS just fine. I finally wound up stepping
through the code one instruction at a time, to find that the
subroutine invocation instruction on this machine was setting a bit in
a register that it wasn't supposed to touch, but only in kernel
mode. An internal OS API change meant it only showed up in the
upgraded OS.

The infamous Pentium floating point bug shows that this case isn't
restricted to failing hardware.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Program help

[Mike Meyer]

"FX" <[EMAIL PROTECTED]> writes:

> can anybody write a code for a program that reads from a
> /location/file & according to file contents, it execute script. e.g. if
> file contains "mp" it runs media player.
> I hope the code is small .. plz help me out!

open http://www.mired.org/downloads/ > will use the extension to
figure out what to do. It's relatively small.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for search engine development

[Mike Meyer]

"corebump" <[EMAIL PROTECTED]> writes:

> hi everybody,
> i planinng develop a search engine and i think using the python. Python
> performance is enough this project? 

If you're going to do the heavy lifting in Python, maybe. It depends
on what you're going to search, and the performance requirements for a
search.

On the other hand, if you use a Python wrapper around a full-text
search facility, so that python finds documents, takes queries and
formats results for the user, it should be just fine.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Automating, Building, Testing and Deploying to Production Server

[Mike Meyer]

"yoda" <[EMAIL PROTECTED]> writes:

> Hi Guys,
> I've been used to deploying code to the production server by checking
> out of subversion and manually sorting out any kinks. (yes, I know, it
> sounds primitive)

Actually, it sounds like your test/development environment is
primitive.  There shouldn't be any "kinks" to sort out by the time you
check things out on the production server.

> How do you automate the process?

I do what you do - except I use perforce instead of svn, and automate
things. There's a development branch, a test branch, and a production
branch for each project. Developers can check things into the
development branch, and integrate from development to test. QA folks
can integrate from test to production. There are daemon processes
running on the test and production servers that do "p4 sync" ("svn up"
to you) once a minute, thus automatically installing new code on the
appropriate server. The QA folks "sort out the kinks" on the test
server, so that the production server doesn't suffer outages from the
development process.

> What tools do you use and how?

Perforce and the python wrapper for same. And of course Python.

> What documentation is available for the various tools?

Bundled with the tools, and on their web sites for perforce and the
wrapper. Lots for Python, all over the place.

> What is the best, easiest, most automated, method that provides robust
> versioning and easy rollback?

The perforce web site has some white papers on "best practices". I
read those - especially the one on web server software - then
implemented what I described above.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:

> Mike Meyer <[EMAIL PROTECTED]> writes:
>> > What convention?  It just makes it possible to write code with some
>> > specific invariants if there's a need to do so.
>> That you don't pass private variables to a function unless it's a builtin.
> No, I don't see that as "convention", it's just something that you do
> if you want to make sure that all the references are local or
> builtins.

Semantics...

> It's like saying that if you if you want to be sure that x
> is always positive, then don't execute statements like "x = -3".  I
> wouldn't call something like that a "convention".

Right - that's not a convention. That behavior would be a convention
if you did somehing like prefixing the variable name with a "p" to
indicate that you don't do that.

> maybe I'd like to be sure that x never yields negative numbers.
> CPython happens to have some features that stop me from guaranteeing
> that invariant.

I'd say CPython was missing the features that you need to guarantee
that. Missing quite a *lot* of features, in fact. But Python has never
been about keeping people from writing bad code - it's about helping
people write good code.

>> It wouldn't catch overriding things in __builtins__ or
>> overriding builtins in a module, or things poking at the variable
>> through __dict__, or - well, there are probably lots of things that
>> need to be dealt with.
> Yes, but I see all of those as implementation artifacts, not anything
> fundamental.

Right - those aren't fundamental. It's things like Python allowing
programmers to use whatever style is appropriate to the problem at
hand, rather than insisting on an OO style. Once you get outside the
OO style, "private" attributes becomes problematic.

>> Preventing accidents is all "private" does - without fundamental
>> changes to the implementation of the language. You have to catch every
>> mechanism that can be used to find a reference to an attribute, like
>> references to __dict__ and to the class variable.
>
> The Python stdlib for a long time had a module called Bastion that
> attempted to do exactly that, so you can't say that the desire is
> un-Pythonic.

Of course I can say it's unpythonic. I might even be right: just
because the standard library does something doesn't mean that
something is automatically pythonic. But I haven't said that "private"
is unpythonic. I will say that the things you need to program
effectively with private variables - like having to inherit all your
utility functions - is unpythonic.

> Bastion was only removed because implementation issues
> kept it from working properly.  Those issues probably can't bbe
> resolved in the 2.x series but as the language evolves, maybe
> something can be done to bring it back.

Pretty much every attempt to restrict what other programmers do in
Python has failed - for "implementation issues". I think that's a good
sign that this kind of thing isn't going to work without some serious
work on the interpreter.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> >> Compile-time restrictions don't matter for squat - you need
>> >> serious restrictions on what the program can do at runtime.
>> > You need both.
>> Yup. Any language besides Java even *try* to provide both for a
>> production environment? 
> Yes.  Python tried.  It had a module called rexec for that purpose.
> I keep mentioning that, and you keep ignoring it.  Rexec was around
> for a long time, and was removed for technical reasons with some
> reluctance.  There is nothing un-Pythonic about the idea.

If you've mentioned it before, it wasn't to me. Or maybe my news
server dropped it. 

Rexec was removed because it didn't work. Just like bastion and every
other attempt to create a "safe" environment in Python. Any security
wonk worth his pay will tell you that you don't add security to
something after the fact if you want good security. You design it in
from the beginning.

Of course, what rexec tried to do and what "private" do are orthogonal
issues.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> Which brings me to my point. Rather than trying to bandage Python to
>> do what you want - and what, based on this thread, a lot of other
>> people *don't* want - you should be building a system from the ground
>> up to support the kind of B&D environment you want.
> Heh, that goes against the principle that Python is supposed to be
> good for everything.

And where did you run into that principle? I've certainly never heard
it before. It's pretty silly principle, as no language is good for
everything. Python is general-purpose, meaning that it's not limited
to a small set of problem areas, and that it probably won't be to bad
for most uses. But that's not the same thing as being "good" for
everything.

Now, one of Python's strengths is that it can glue other applications
together. So you can, for instance, write your application-specific
code in a language suitable for that problem domain, then wrap those
objects for use in a python interpreter - which is very popular in
scientific circles - and optionally embed the interpeter in your
application so you can invoke scripts as a fundamental part of your
application. This makes it possible to deal with that application area
with Python - but it doesn't mean Python is good for writing code for
that application; just that it's good for wrapping other languages.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> I'd say CPython was missing the features that you need to guarantee
>> that. Missing quite a *lot* of features, in fact. But Python has never
>> been about keeping people from writing bad code - it's about helping
>> people write good code.
> Privilege separation is considered a good coding practice.  How does
> Python help it?

With conventions and name mangling. Which are only slightly less
effective than the C++/Java technic for doing the same thing.

>> Pretty much every attempt to restrict what other programmers do in
>> Python has failed - for "implementation issues". I think that's a good
>> sign that this kind of thing isn't going to work without some serious
>> work on the interpreter.
> You could take it as a sign that the interpreter could benefit from
> some serious work.

If you want it to become a secure environment to run untrusted code
in, then it definitely neede some serious work. I'd recommend starting
by copying /dev/null over all the .c and .h files. Of course, not
everyone wants that from Python, so they don't get any benefit from
such work.

> I don't know the situation in Jython.

I was going to suggest Jython as a better bet for getting something
rexec-like to work. Java was at least intended to provide a secure
environment to run untrusted code in, so you're not building on
quicksand. IronPython might also be worth a look, based on what little
(and it's very little) I know about .NET.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> > Privilege separation is considered a good coding practice.  How does
>> > Python help it?
>> With conventions and name mangling. Which are only slightly less
>> effective than the C++/Java technic for doing the same thing.
> That's not what privilege separation means.  It means that the
> privileged objects stay secure even when the unprivileged part of the
> program is completely controlled by an attacker.

In which case, what's "private" got to do with this? The examples I've
seen of it don't give you privilege seperation any more than python
does.

Of course, while we're adding things to Python to support what people
consider good coding practices, let's not forget:

 Design by contract.
 Covariant method specialization.
 Class invariants.
 Avoiding variable aliasing.
 Hungarian Notation.
 The Law of Demeter.
 Loop invariants.
 Avoiding mixed mode arithmetic.
 The telephone test.
 Procedure/function sepration.
 Type discipline.
 Contravariant method specialization.

and so on.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin  writes:
>> > That's not what privilege separation means.  It means that the
>> > privileged objects stay secure even when the unprivileged part of the
>> > program is completely controlled by an attacker.
>> In which case, what's "private" got to do with this? The examples I've
>> seen of it don't give you privilege seperation any more than python does.
> If you have a java class instance with a private member that's (say) a
> network socket to a special port, access to the port is controlled
> entirely by that class.

Are you sure? My understanding was that Java's introspection mechanism
could be used to access private variables.

A couple of other things to think about:

Are you sure you want to use the C++ model for privilege separation?
C++'s design doesn't exactly inspire confidence in me. I'd recommend
checking languages that were designed to be OO from scratch, rather
than as extensions or rewrites of other languages. I'd also check
dynamic languages to see if any of them do this - other than PHP,
which apparently adopted the C++ model, and is another language I
wouldn't trust for inspiration.

In static languages, information of this kind is normally attached to
variables. In Python, the only thing a variable knows is the object it
references. So do you want the privilege information attached to the
variable or the object it references? If you attach it to the
variable, you're again making what appears to be a fundamental change
in Python, and possibly invoking serious implementation headaches. If
you attach it to the object, you solve a lot of the problems Pythons
reference model creates, but you also leave open the possibility of
simple assignment changing an attribute.

Finally, another hole to fix/convention to follow to make this work
properly in Python. This one is particularly pernicious, as it allows
code that doesn't reference your class at all to violate the private
variables. Anyone can dynamically add methods to an instance, the
class it belongs to, or to a superclass of that class. This means code
in one place can add a method to a superclass of your class that
clobbers your private variable, which can then be invoked on an
instance of your class to surprise you. So you may have to examine
code that doesn't reference your class at all to find the statement
that is clobbering your private variable.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Mike Meyer]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Mon, 03 Oct 2005 06:59:04 +, Antoon Pardon wrote:
> Declared variables have considerable labour costs, and only marginal
> gains. Since the steps you take to protect against other errors will also
> protect against mistyping variables, declarations of variables is of
> little practical benefit.

As far as I can tell, this is as much hearsay and personal experience
as the alternate claim that not having them costs you lots of
debugging time and errors. If anyone has pointers to real research
into this area (I've heard the TRAK folks did some, but haven't been
able to turn any up), I'd love to hear it.

My gut reaction is that it's a wash. The time taken to declare
variables in well-written code in a well-designed language - meaning
the declarations and use will be close together - isn't all that
great, but neither are the savings.

The other win from declaring variables is that if you compile the code
you can make assumptions about the types of variables and thus save
doing (some of) the type determination at run time. But there are type
inferencing languages and systems - and they've been around since the
70s - that can do that for you without having to declare the
variables, so that doesn't buy you much.

If I'm going to get compiler support for semantic checking like this,
I want it to serious levels. I want function pre/post conditions
checked. I want loop and class invariant checked. I want subsumption
in my inheritance tree. Nuts - I want a complete, well-designed
inheritance tree. Duck typing is great stuff, but if I'm going to be
doing the work to declare everything, I want *everything* that can be
checked checked.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reply-To header

[Mike Meyer]

Peter Decker <[EMAIL PROTECTED]> writes:
> Setting the default Reply-To: to the list means that 'Reply' sends
> just to the list (the desired behavior most of the time), and 'Reply
> to all' sends 2 copies.

No, it sends one copy to the list, and one copy to the original
author. This is the behavior you want. The author may not be
subscribed to the list. Such people are most in need of help, and you
want the default to be that they get help.

There are a number of alternatives for users on the list to avoid
getting duplicates. Many lists can be configured to check the headers
for other recipients, and to remove them from the list for that
message. Many mail readers have functionality to detect and eliminate
duplicates - even MS LookOut has that! Personally, I wrote a qmail
dot-command to do it long ago. I can make my dot-commands available if
anyone wants them. There's also a mail header that's been around for
years that tells conforming agents to supress the copy to the
author. Some mail readers honor it, others don't.

> I'm on several other lists, some of which default replies to the list,
> and others which default to the sender. I've *never* seen threads like
> this on the former, while such threads appear like clockwork on the
> latter. Draw your own conclusion.

I see the threads you don't see. Usually started by someone accidently
sending a reply that was very much intended to be private to a public
list. This should be compared to the badness of hitting the wrong
reply when the list is configured properly: only one person gets a
copy. That's easily fixed by asking them to forward it to the list, or
simply reposting your message, with little or no harm done.

My conclusion is that people used to the correct behavior have given
up on fixing the internet, and use tools that fix the part of it they
can see. When I notice that a list is broken (RFC 2822 says that
reply-to is for the *author* of the message; anyone else setting it is
doing so in violation of the RFC, and hence broken, no matter how
useful it may be), I tell my mailer to ignore reply-to on mail from
that list. Similarly, I no longer try and explain to people how long
lines violate RFCs and are a pain to read in well-behave mail readers,
or why mail readers that wrap text/plain content are broken.
Likewise, I restrict my comments on top posting to noting that I've
fixed it (or given up on fixing it and deleted the text as useless)
when I follow up to such things. Asking people to change their ways
because it's better for others is a waste of time - most of the users
on the internet these days don't give shit.

>> Not that it matters that much to me, since I read practically all
>> mailing lists via gmane.org. That turns the lists into newsgroups, where
>> the reply button (follow-up, more accurately) does send the reply to the
>> newsgroup.
> So the answer is to not use the email interface, since the newsgroup
> interface actually gets it right!  :)

Newsreaders only gets it right if it sends copies to posters who
aren't subscribed.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reply-To header

[Mike Meyer]

Roel Schroeven <[EMAIL PROTECTED]> writes:
> Peter Decker wrote:
>> Setting the default Reply-To: to the list means that 'Reply' sends
>> just to the list (the desired behavior most of the time), and 'Reply
>> to all' sends 2 copies.
> The thing is: Reply-to has legitimate uses. I don't really understand
> the use cases (AFAICS all of them could be done with Form: instead)

Yes, they can all be done with From:. But From: has uses other than
just listing the reply address, and if you hijack From: to replace
reply-to (because other people have hijacked Reply-To: for purposes
for which it wasn't intended :-), then you can't use From: for what
*it* was intended for.

I send out mail - well, mail gets sent out for me - every day that
uses both the From: and Reply-To: fields. The mail is *from* me, and
that's what the from header says. The reply needs to go to a magic
maildrop that takes action based on the reply address. The recipient
doesn't need to see the reply address, and would only be confused by
it if they did.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reply-To header

[Mike Meyer]

Roel Schroeven <[EMAIL PROTECTED]> writes:
> Is that really the desired behaviour? IMO the least you can do if you're
> searching for help is subscribing to the mailing list on which you're
> looking for help. Me and many others don't like to receive replies
> directly instead of via the mailing list; it's of no use, since we're
> subscribed to the mailing list anyway.

Rather than asking everyone else to modify their behavior for your
convenience, why don't you fix the problem at your end? Check to see
if the list will filter duplicates for you. Check to see if your
mailer will filter duplicates for you. Or grit and bear it. You'll
almost certainly get less unwanted mail from people who send you
duplicates in reply to your messages than they would get from
subscsribing to the list.

In short - starting thinking about the greater good rather than your
own best interest.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Mike Meyer]

Paul Rubin  writes:
>> A couple of other things to think about:
>> Are you sure you want to use the C++ model for privilege separation?
> I'm not sure what you mean by the C++ model.  If you mean the Java
> model, as I keep saying, applet sandbox security relies on it, so it
> may not be perfect but it's not THAT bad.  Using it routinely in
> normal applications would be a big improvement over what we do now.
> High-security applications (financial, military, etc.) would still
> need special measures.

I assumed the Java model was based on the C++ model because it seems
that everything in Java is based on C++, and they share the same
vocabulary. If I'm wrong - well, that means you considered another
language already.

Sure, Java might be a big improvement. But Python isn't Java. Rather
than just throwing in something that works, do the legwork to verify
that you're going to propose a best-of-breed solution. If something
perfect is available, wouldn't you feel awful if Python got saddled
with something that wasn't perfectd?

>> Finally, another hole to fix/convention to follow to make this work
>> properly in Python. This one is particularly pernicious, as it allows
>> code that doesn't reference your class at all to violate the private
>> variables. Anyone can dynamically add methods to an instance, the
>> class it belongs to, or to a superclass of that class. 
>
> Yes, Python isn't even type-safe any more:
>
> class A(object): pass
> class B(object): pass
> a = A()
> print type(a)
> a.__class__ = B
> print type(a)# oops

No, that's not the feature I was talking about. But it is *yet
another* hole you have to deal with.

> IMHO that "feature" you describe is quite inessential in Python.  The
> correct way to override or extend the operations on a class is to
> subclass it.  I can't think of a single place where I've seen Python
> code legitimately go changing operations by jamming stuff into the
> class object.  I'd consider the stdlib's socket.py to be illegitimate
> and it cost me a couple of hours of debugging one night:

Note that you can extend an instance as well as a class, though it's a
bit more baroque to do so. But people use the ability to add a method
to a class dynamically when they want to switch between behaviors for
all objects in the class at run time. Personally, I would use a
dictionary of methods, but I don't see anything particulary wrong with
the latter approach - unless you just dislike dynamic code. Yanking a
feature because it gets misued in one place means we should probably
pre-emptively yank private to keep people from declaring things
private when they shouldn't be.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: packaging a python project and associated graphics files

[Mike Meyer]

Rajarshi Guha <[EMAIL PROTECTED]> writes:

> Hi, I've been trying to package a python project and I'm a little confused
> about how I distribute some PNG's that the program uses as icons.
>
> Using distutils I can set the data_files argument of setup() and get my
> data files located in, say, /usr/local/mydata.
>
> However when I write my code, it would seem that I have to hardcode the
> above path. But this would mean that while working on the code I would
> need to have it 'installed' on my system (or else actually make the above
> directory).
>
> This seems a little unwieldy. How do people handle this situation?

With symlinks from the installed location to the source tree.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Controlling who can run an executable

[Mike Meyer]

"Cigar" <[EMAIL PROTECTED]> writes:
> Now that I'm three months into the development of this program, my
> client tells me she would like to protect her investment by preventing
> her employees from doing the same to her.  (Going to the competition
> and using her program.)

First thing to know; you can't stop someone who's sufficiently
determined to run the program. The best you can do is raise the cost
of breaking your security to be more than any value that could be
gained from doing so.

> What my client cannot prevent:
> - access to the .exe
>
> What my client is looking to prevent:
> - running of the exe by un-authorized individuals.

Not quite.

> Ideas I've had to prevent someone from running the app:
> - ask for a password every time the program is run. (I wonder how
> quickly they will complain about this, not very secure once everyone
> eventually finds out what the password is)

If only authorized people have the password, then this works. The
problem is that her employees are probably authorized, but she doesn't
trust them to not take the program to her competition. Which brings
up an alternative goal:

Prevent running of the exe on unauthorized hardware.

> - make a little hardware dongle and check to see if it's on the
> parallel port. (old idea)
> - check for an encrypted flash drive and try to read an encrypted file
> from it. (new idea)
> - buy the client a Microsoft Fingerprint Keyboard and figure out if it
> will make the clients life easier (two minutes of research showed this
> idea has multiple problems)

Note that these three all use the idea of unauthorized hardware, not
people.

You don't need to install special hardware to get that. There are a
number of pieces of hardware that you can find in a modern computer
that may have a unique serial number you can use as a
dongle. Possibilities include a CPU serial number, an HD serial
number, and the MAC address of any network cards: ethernet, wireless,
and apparently FireWire drivers have them. People have used all of
them in the past.

> What I want:
> - the simplest thing that could possibly work!

Telling her "Don't let your employees near the computer with media, or
when it's connect to a network."  That could possibly work, for some
definition of work. You need to define how difficult you want breaking
your security to be. Then we know what "work" means, and can figure
out what "the simplest thing" is.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Mike Meyer]

Antoon Pardon <[EMAIL PROTECTED]> writes:
> Op 2005-10-03, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
>> On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
> Declarations also allow easier writable closures. Since the declaration
> happens at a certain scope, the run time can easily find the correct
> scope when a variable is rebound.

If it happens at runtime, then you can do it without declarations:
they're gone by then. Come to think of it, most functional languages -
which are the languages that make the heaviest use of closures - don't
require variable declarations.

> They also relieve a burden from the run-time, since all variables
> are declared, the runtime doesn't has to check whether or not
> a variable is accesible, it knows it is.

Not in a dynamic language. Python lets you delete variables at run
time, so the only way to know if a variable exists at a specific
point during the execution of an arbitrary program is to execute the
program to that point.

> And if you provide type information with the declaration, more
> efficient code can be produced.

Only in a few cases. Type inferencing is a well-understood
technology, and will produce code as efficient as a statically type
language in most cases.

> I think language matters shouldn't be setlled by personal preferences.

I have to agree with that. For whether or not a feature should be
included, there should either be a solid reason dealing with the
functionality of the language - meaning you should have a set of use
cases showing what a feature enables in the language that couldn't be
done at all, or could only be done clumsily, without the feature.

Except declarations don't add functionality to the language. They
effect the programing process. And we have conflicting claims about
whether that's a good effect or not, all apparently based on nothing
solider than personal experience. Which means the arguments are just
personal preferences.

Until someone does the research to provide hard evidence one way or
another, that's all we've got to work with. Which means that languages
should exist both with and with those features, and if one sides
experiences generalize to the population at large, they alternative
languages will die out. Which hasn't happened yet.

> But we should decide what language features are usefull and which are
> not by what some individual can or can't live without.

Um - that's just personal preference (though I may have misparsed your
sentence). What one person can't live without, another may not be able
to live with. All that means is that they aren't likely to be happy
with the same programming language. Which is fine - just as no
programming language can do everything, no programming language can
please everyone.

Antoon, at a guess I'd say that Python is the first time you've
encountered a dynamnic language. Being "horrified" at not having
variable declarations, which is a standard feature of such languages
dating back to the 1950s, is one such indication.

Dynamic languages tend to express a much wider range of programming
paradigms than languages that are designed to be statically
compiled. Some of these paradigms do away with - or relegate to the
level of "ugly performance hack" - features that someone only
experienced with something like Pascal would consider
essential. Assignment statements are a good example of that.

Given these kinds of differences, prior experience is *not* a valid
reason for thinking that some difference must be wrong. Until you have
experience with the language in question, you can't really decide that
some feature being missing is intolerable. You're in the same position
as the guy who told me that a language without a goto would be
unusable based on his experience with old BASIC, FORTRAN IV and
assembler.

Pick one of the many languages that don't require declarations. Try
writing a code in them, and see how much of a problem it really is in
practice, rather than trying to predict that without any
information. Be warned that there are *lots* of variations on how
undeclared variables are treated when referenced. Python raises
exceptions. Rexx gives them their print name as a value. Other
languages do other things.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Mike Meyer]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
>> My gut reaction is that it's a wash. The time taken to declare
>> variables in well-written code in a well-designed language - meaning
>> the declarations and use will be close together - isn't all that
>> great, but neither are the savings.
> You've gone from thinking about the implementation of the algorithm to
> thinking about how to satisfy the requirements of the compiler. As
> context switches go, it isn't as big as the edit-compile-make-run
> method of testing, but it is still a context switch.

I'm making context switches all the time when programming. I go from
thinking about the problem in terms of the problem, to thinking about
in terms of programming language objects, to thinking about the syntax
for expressing those objects. Adding another one does have a cost -
but it's no big deal.

> I don't know whether there are languages that will check everything in
> that way. If there aren't, then perhaps there should be. But Python
> shouldn't be one of them.

Right. You're doing different things when you program in a language
like Python, vs. Eiffel (which is where I drew most of my checks
from). Each does what it does well - but they don't do the same
things.

> Specifying every last detail about the objects making up the space
> shuttle is one of the reasons why it costs umpty-bazillion dollars
> to build one, and almost as much to maintain it -- and it still has
> a safety record worse than most $10,000 cars.

As if a something that's designed to literally blow you off the face
of the earth could reasonably be compared with an internal combustion
engine that never leaves the ground for safety. The shuttle has one of
the best safety records around for vehicles that share it's
purpose. It's doing something that's inherently very dangerous, that
we are still learning how to do. Overengineering is the only way to
get any measure of safety.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reply-To header

[Mike Meyer]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
>> When I notice that a list is broken (RFC 2822 says that
>> reply-to is for the *author* of the message; anyone else setting it is
>> doing so in violation of the RFC, and hence broken, no matter how
>> useful it may be),
> Since when did obeying the RFC become important in and of itself?

Since we started worrying about software being interoperable. If you
only use software from one monopolistic vendor, then that won't matter
to you, and you'll create pain and suffering for everyone who doesn't
drink the same koolaide. But such attitudes seem endemic on the
internet these days.

> That's what reply to means, surely? What is the point of a reply-to
> header that must be the sender, since you already have a header that
> gives you the sender.

You misunderstood. By "for the *author*", I meant that it's for the
*author* to set, not for someone else to set. I did not mean that it
had to be set to a specific value. Saying that anyone else setting it
is broken should have made that clear.

> I have been known to change the reply-to address from the address I am
> sending from ([EMAIL PROTECTED] for example) to the address I want the reply 
> to
> go to ([EMAIL PROTECTED]). There are many times I'm emailing people I know 
> can't
> cope with the complicated task of changing the To address of their
> reply, so I change the reply-to header so that their reply goes where
> I want it to go to (which might be another email address of mine, or a
> different person, or a mailing list).

And these are perfectly valid uses of reply-to. You're the author,
you're the one that reply-to is there for.

> If the RFC says that the reply-to header doesn't actually mean the
> address the reply should go to, but only the sender, then the RFC is
> broken. "Where the reply goes to" is a *human* decision, not a
> technical one. If I send you an email saying "Please reply to
> [EMAIL PROTECTED]" then your mailer should honour that
> (although, since we are all adults, you should have the freedom to
> ignore my request and make a nuisance of yourself by emailing your
> reply to a different address).

That isn't what the RFC says, as you could have easily checked. It's
also not what I said.

> Likewise, if I set the reply address to the list, then your mailer
> should reply to the list. Perhaps you can argue that *my decision* to
> have replies go to the list is a bad one, but that's a social issue,
> not a technical one.

You're the author of the message. If you set the reply-to, that's
fine. If anyone other than you sets the reply-to, that's broken.

>> I tell my mailer to ignore reply-to on mail from
>> that list. Similarly, I no longer try and explain to people how long
>> lines violate RFCs and are a pain to read in well-behave mail readers,
> By "well-behaved", do you mean "can't cope with long lines"? How
> curious -- that's precisely the opposite definition of well-behaved I
> use.
>> or why mail readers that wrap text/plain content are broken.
> Curiouser and curiouser. Again that's the exact opposite of my
> definition of broken.

Like I said, I gave up on this fight. Ignorant people are going to
continue generating ugly, hard-to-read messages and complaining when
they get a message that demonstrates why their software is
broken. That's life on the internet these days. The internet used to
be a nice neighborhood. Now it's full of selfish jerks, and there are
to many of them to fight.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ssh or other python editor

[Mike Meyer]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>>- I'm a newbie at freeBSD so I think there is , but I don't know where.
> Putty isn't doing any syntax coloring; it just draws things in the color 
> specified
> by your editor.  If you don't get any colors, it's probably because your 
> editor
> isn't properly configured.  Explicitly setting the TERM variable to "xterm" 
> might
> help:
>
> http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-term

According to the FAQ, putty sets it to xterm. I use xter-color on
FreeBSD.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie Text Processing Question

[Mike Meyer]

[EMAIL PROTECTED] writes:
> I'm a total newbie to Python so any and all advice is greatly
> appreciated.

Well, I've got some for you.

> I'm trying to use regular expressions to process text in an SGML file
> but only in one section.

This is generally a bad idea. SGML family languages aren't easy to
parse - even the ones that were designed to be easy to parse - and
generally require very complex regular expessions to get right. It may
be that your SGML data can be parsed by the re you use, but there
are almost certainly valid SGML documents that your parser will not
properly parse.

In general, it's better to use a parser for the language in question.

> So the input would look like this:
>
> RESEARCH GUIDE
> content
> content
>
> content
> content
>
>
> FORMS
> content
>
> content
> content
>
> content
> content


This is funny-looking SGML. Are the the end tags really optional for
all the tag types?

> But no matter what I try I end up changing the entire file rather than
> just one part.

Other have explained why you can't do that, so I'll skip it.

> Here's what I've come up with so far but I can't think of anything
> else.
>
> ***
>
> import os, re
> setpath = raw_input("Enter the path where the program should run: ")
> print
>
> for root, dirs, files in os.walk(setpath):
>  fname = files
>  for fname in files:
>   inputFile = file(os.path.join(root,fname), 'r')
>   line = inputFile.read()
>   inputFile.close()
>
>
>   chpart_pattern = re.compile(r' no=\"[A-Z]{1,4}\">(RESEARCH)', re.IGNORECASE)

This makes a number of assumptions that are invalid about SGML in
general, but may be valid for your sample text - how attributes are
quoted, the lack of line breaks, which can be added without changing
the content, and the format of the "no" attribute.

>   while 1:
>if chpart_pattern.search(line):
> line = re.sub(r" no=(\"[0-9]*.[0-9]*\")>(.*)", r" no=\1>\2\n", line)

Ditto.

Heren's an sgmllib solution that gets does what you do above, except
it writes it to standard out:

#!/usr/bin/env python

import sys
from sgmllib import SGMLParser

datain = """
RESEARCH GUIDE
content
content

content
content


FORMS
content

content
content

content
content
"""

class Parser(SGMLParser):

def __init__(self):
# install the handlers with funny names
setattr(self, "start_ch-part", self.handle_ch_part)

# And start with chapter 0
self.ch_num = 0

SGMLParser.__init__(self)

def format_attributes(self, attributes):
return ['%s="%s"' % pair for pair in attributes]

def unknown_starttag(self, tag, attributes):
taglist = self.format_attributes(attributes)
taglist.insert(0, tag)
sys.stdout.write('<%s>' % ' '.join(taglist))

def handle_data(self, data):
sys.stdout.write(data)

def handle_ch_part(self, attributes):
"""This should be called start_ch-part, but, well, you know."""

self.unknown_starttag('ch-part', attributes)
for name, value in attributes:
if name == 'no':
self.ch_num = value

def start_para(self, attributes):
if self.ch_num == 'I':
sys.stdout.write('\n')
self.unknown_starttag('para', attributes)


parser  = Parser()
parser.feed(datain)
parser.close()


sgmllib isn't a very good SGML parser - it was written to support
htmllib, and really only handles that subset of sgml well. In
particular, it doesn't really understand DTDs, so can't handle the
missing end tags in your example. You may be able to work around that.

If you can coerce this to XML, then the xml tools in the standard
library will work well. For HTML, I like BeautifulSoup, but that's
mostly because it deals with all the crud on the net that is passed
off as HTML. For SGML - well, I don't have a good answer. Last time I
had to deal with real SGML, I used a C parser that spat out a parse
tree that could be parsed properly.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Mike Meyer]

Antoon Pardon <[EMAIL PROTECTED]> writes:
>>> They also relieve a burden from the run-time, since all variables
>>> are declared, the runtime doesn't has to check whether or not
>>> a variable is accesible, it knows it is.
>> Not in a dynamic language. Python lets you delete variables at run
>> time, so the only way to know if a variable exists at a specific
>> point during the execution of an arbitrary program is to execute the
>> program to that point.
> It is not perfect, that doesn't mean it can't help. How much code
> deletes variables.

It's not perfect means it may not help. Depends on the cost of being
wrong - which means we need to see how things would be different if
the code was assuming that a variable existed, and then turned out to
be wrong.

Actually, I'd be interested in knowing how you would improve the
current CPython implementation with knowledge about whether or not a
variable existed. The current implementation just does a dictionary
lookup on the name. The lookup fails if the variable doesn't exist. So
checking on the existence of the variable is a byproduct of finding
the value of the variable. So even if it was perfect, it wouldn't
help.

>>> And if you provide type information with the declaration, more
>>> efficient code can be produced.
>> Only in a few cases. Type inferencing is a well-understood
>> technology, and will produce code as efficient as a statically type
>> language in most cases.
> I thought it was more than in a few. Without some type information
> from the coder, I don't see how you can infer type from library
> code.

There's nothing special about library code. It can be anaylyzed just
like any other code.

>>> I think language matters shouldn't be setlled by personal preferences.
>> I have to agree with that. For whether or not a feature should be
>> included, there should either be a solid reason dealing with the
>> functionality of the language - meaning you should have a set of use
>> cases showing what a feature enables in the language that couldn't be
>> done at all, or could only be done clumsily, without the feature.
> I think this is too strict. Decorators would IMO never made it.

>From the impressions I get here, a lot of people would have been happy
with that result.

> I think that a feature that could be helpfull in reduction
> errors, should be a candidate even if it has no other merrits.

Yes, but that doesn't mean it should be accepted. Otherwise, every
language would be Eiffel. You have to weigh the cost of a feature
against the benefit you get from it - and different people come to
different conclusions. Which is why different languages provide
different levels of bondage.

>> Except declarations don't add functionality to the language. They
>> effect the programing process.
> It would be one way to get writable closures in the language.
> That is added functionality.

Except just adding declerations doesn't give you that. You have to
change the language so that undeclared variables are looked for up the
scope. And that's the only change you need to get writable variables -
some way to indicate that a variable should be checked for up the
scope. There are more lightweight ways to do that than tagging every
*other* variable. Those have been proposed - and rejected.

>> And we have conflicting claims about
>> whether that's a good effect or not, all apparently based on nothing
>> solider than personal experience. Which means the arguments are just
>> personal preferences.
> Whether the good effect is good enough is certainly open for debate.
> But the opponents seem to argue that since it is no absolute guarantee,
> it is next to useless. Well I can't agree with that kind of argument
> and will argue against it.

You're not reading the opponents arguments carefully enough. The
argument is that the benefit from type declerations is overstated, and
in reality doesn't outweigh the cost of declerations.

>> Antoon, at a guess I'd say that Python is the first time you've
>> encountered a dynamnic language. Being "horrified" at not having
>> variable declarations, which is a standard feature of such languages
>> dating back to the 1950s, is one such indication.
> No I'm not horrified at not having variable declarations. I'm in
> general very practical with regard to programming, and use what
> features a language offers me. However that doesn't stop me from
> thinking: Hey if language X would have feature F from language Y,
> that could be helpfull.

I'm sorry - I thought you were the OP, who said he was horrified by
that lack.

>> Dynamic languages tend to express a much wider range of programming
>> paradigms than languages that are designed to be statically
>> compiled. Some of these paradigms do away with - or relegate to the
>> level of "ugly performance hack" - features that someone only
>> experienced with something like Pascal would consider
>> essential. Assignment statements are a good example of that.
> I think we should get rid of thinking 

Re: "no variable or argument declarations are necessary."

[Mike Meyer]

Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
> Mike Meyer a écrit :
>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> 
>>>Op 2005-10-03, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
>>>
>>>>On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
>>>
>>>Declarations also allow easier writable closures. Since the declaration
>>>happens at a certain scope, the run time can easily find the correct
>>>scope when a variable is rebound.
>> If it happens at runtime, then you can do it without declarations:
>> they're gone by then. Come to think of it, most functional languages -
>> which are the languages that make the heaviest use of closures - don't
>> require variable declarations.
> Well, can you give a single example of such language ? Because all the
> functionnal language I know but one do need variable declaration : lisp,
> scheme, ocaml, haskell do need variable declaration ! Erlang do not ...

Scheme and lisp don't need variable declerations. Last time I looked,
Schemd didn't even *allow* variable declerations.

>> Only in a few cases. Type inferencing is a well-understood
>> technology, and will produce code as efficient as a statically type
>> language in most cases.
> Type inferencing only works for statically typed languages AFAIK ! In a
> dynamically typed languages, typing a variable is simply impossible as
> any function may return a value of any type !

I think we're using different definitions of statically typed
here. A language that is statically typed doesn't *need* type
inferencing - the types are all declared! Type determines the thypes
by inferenceing them from an examination of the program. So, for
instance, it can determine that this function:

def foo():
return 1

Won't ever return anything but an integer.

>>>I think language matters shouldn't be setlled by personal preferences.
>> I have to agree with that. For whether or not a feature should be
>> included, there should either be a solid reason dealing with the
>> functionality of the language - meaning you should have a set of use
>> cases showing what a feature enables in the language that couldn't be
>> done at all, or could only be done clumsily, without the feature.
> Wrong argument ... with that kind of things, you would just stick with
> plain Turing machine ... every single computation can be done with it !

"Computation" is is not the same thing as "Functionality". If you
think otherwise, show me how to declare an object with a Turing
machine.

And there's also the issue of "clumsily". Turing machines are clumsy
to program in.


>> Except declarations don't add functionality to the language. They
>> effect the programing process. And we have conflicting claims about
>> whether that's a good effect or not, all apparently based on nothing
>> solider than personal experience. Which means the arguments are just
>> personal preferences.
> Well, so why not *allow* for variable declaration ? Languages like Perl
> does that successfully ... you don't like : you don't do ! you like :
> you do ! A simple option at the beginning of the file tell the compilor
> if variable declaration is mandatory or not !

Perl is a red herring. Unless it's changed radically since I last
looked, undeclared variables in Perl have dynamic scope, not lexical
scope. While dynamically scoped variables are a powerful feature, and
there have been proposals to add them to Python, having them be the
default is just *wrong*. If I were writing in Perl, I'd want
everything declared just to avoid that. Of course, if Python behaved
that way, I'd do what I did with Perl, and change languages.

>> Antoon, at a guess I'd say that Python is the first time you've
>> encountered a dynamnic language. Being "horrified" at not having
>> variable declarations, which is a standard feature of such languages
>> dating back to the 1950s, is one such indication.
> Dynamic language and variable declaration are non-related issues ! You
> can have statically-typed language without variable declaration (i.e.
> BASIC) and dynamically-typed language with (i.e. Lisp) ! Please, when
> you says something about languages, at least give 1 name of language
> asserting what you're saying !

Declerations and typing are *also* non-related issues. See Perl. Also
see the subject line.

>> Dynamic languages tend to express a much wider range of programming
>> paradigms than languages that are designed to be statically
>> compiled. Some of these paradigms do away with - or relegate to the
>> level of "ugly performance hack" - fea

Re: "no variable or argument declarations are necessary."

[Mike Meyer]

Paul Rubin <http://[EMAIL PROTECTED]> writes:

> Mike Meyer <[EMAIL PROTECTED]> writes:
>> I think we're using different definitions of statically typed
>> here. A language that is statically typed doesn't *need* type
>> inferencing - the types are all declared! Type determines the thypes
>> by inferenceing them from an examination of the program. 
>
> I thought static typing simply means the compiler knows the types of
> all the expressions (whether through declarations or inference) so it
> can do type checking at compile time:
>
>> So, for instance, it can determine that this function:
>> 
>> def foo():
>> return 1
>> 
>> Won't ever return anything but an integer.
>
> Static typing in this case would mean that re.match('a.*b$', foo())
> would get a compile time error, not a runtime error, since re.match
> expects two string arguments.  This can happen through type inference
> w/o declarations.

Except for two problems:

One you noted:

> Note apropos the private variable discussion that CPython can't
> guarantee that foo() always returns an integer.  Something might
> change foo.func_code.co_code or something like that.

Two is that dynamic binding means that foo may not refer to the above
function when you get there at run time.

>> Maybe you're still writing code for a language with declerations? I
>> never felt that need. Then again, I came to Python from a language
>> that didn't require declerations: Scheme.
> I've done a fair amount of Lisp programming and have found the lack of
> compile-time type checking to cause about the same nuisance as in
> Python.

So have I - basically none at all.

>> > Well, in the end, I would really like an *option* at the beginning of a
>> > module file requiring variable declaration for the module. It would
>> > satisfy both the ones who want and the ones who don't want that ...
>> Nope. It would just change the argument from "Python should have ..."
>> to "You should always use ..." or "Module foo should use ...".
> Perl has a feature like that right now, and it doesn't lead to many such
> arguments.

As noted elsewhere, Perl isn't a good comparison. You don't simply say
"This variable exists", you say "this variable is local to this
function". Undeclared variables are dynamically bound, which means you
can get lots of non-obvious, nasty bugs that won't be caught by unit
testing. Making all your variables lexically bound (unless you really
need a dynamically bound variable) is a good idea. But that's already
true in Python.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Mike Meyer]

Barbier de Reuille <[EMAIL PROTECTED]> writes:

> Dans l'article <[EMAIL PROTECTED]>, Mike Meyer a écrit :
>> Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
>>> Mike Meyer a écrit :
>>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>> 
>>>>>Op 2005-10-03, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
>>>>>
>>>>>>On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
>>>>>
>>>>>Declarations also allow easier writable closures. Since the declaration
>>>>>happens at a certain scope, the run time can easily find the correct
>>>>>scope when a variable is rebound.
>>>> If it happens at runtime, then you can do it without declarations:
>>>> they're gone by then. Come to think of it, most functional languages -
>>>> which are the languages that make the heaviest use of closures - don't
>>>> require variable declarations.
>>> Well, can you give a single example of such language ? Because all the
>>> functionnal language I know but one do need variable declaration : lisp,
>>> scheme, ocaml, haskell do need variable declaration ! Erlang do not ...
>> 
>> Scheme and lisp don't need variable declerations. Last time I looked,
>> Schemd didn't even *allow* variable declerations.
>
> When you want local variable in lisp you do :
>
> (let ((a 3)) (+ a 1))

Excep that's not a decleration, that's a binding. That's identical to
the Python fragment:

   a = 3
   return a + 1

except for the creation of the new scope. Not a variable decleration
in site.

> For global variable you may do:
>
> (defparameter *a* 4)
>
> or:
>
> (defvar *a* 4)

That's not Scheme. When I was writing LISP, those weren't
required. Which is what I said: variable declarations aren't required,
and aren't allowedd in Scheme.

> However, either way, variable assignment is done via :
>
> (setf *a* 5)
> (setf a 10)
>
> This is what I call variable declaration as you have different way
> to declare global variables and to assign them ... So the
> two operations are well defined and different.

Python uses "global foo" to declare global variables.

> And here there is a difference between static language and
> declarative ones ... Lisp is a dynamic language that needs variable
> declarations.

LISP doesn't need variable declarations. I certainly never wrote any
when I was writing it.

>>>> Except declarations don't add functionality to the language. They
>>>> effect the programing process. And we have conflicting claims about
>>>> whether that's a good effect or not, all apparently based on nothing
>>>> solider than personal experience. Which means the arguments are just
>>>> personal preferences.
>>> Well, so why not *allow* for variable declaration ? Languages like Perl
>>> does that successfully ... you don't like : you don't do ! you like :
>>> you do ! A simple option at the beginning of the file tell the compilor
>>> if variable declaration is mandatory or not !
>> 
>> Perl is a red herring. Unless it's changed radically since I last
>> looked, undeclared variables in Perl have dynamic scope, not lexical
>> scope. While dynamically scoped variables are a powerful feature, and
>> there have been proposals to add them to Python, having them be the
>> default is just *wrong*. If I were writing in Perl, I'd want
>> everything declared just to avoid that. Of course, if Python behaved
>> that way, I'd do what I did with Perl, and change languages.
>
> I never said to adopt the whole Perl variable semantic. I just pointed
> what I think is a good idea in Perl and that help (IMHO) precising what
> I intended ...

And I pointed out that it's a good idea in Perl because it does
something that it doesn't need doing in Python.

>>>> Dynamic languages tend to express a much wider range of programming
>>>> paradigms than languages that are designed to be statically
>>>> compiled. Some of these paradigms do away with - or relegate to the
>>>> level of "ugly performance hack" - features that someone only
>>>> experienced with something like Pascal would consider
>>>> essential. Assignment statements are a good example of that.
>>> Well, could you be more specific once more ? I can't that many paradigm
>>> only available on dynamically typed languages ... beside duck-typing
>>> (which is basically a synonym for dynamically-typed)
>

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Mike Meyer]

Grant Edwards <[EMAIL PROTECTED]> writes:
> On 2005-10-06, DaveM <[EMAIL PROTECTED]> wrote:
>>>Frankly, I can't watch Shakespeare or movies like "the full
>>>monty" or "trainspotting" because I can't understand a damn
>>>word they say. British talk sounds like gibberish to me for the
>>>most part.
>> Not just you. It always amuses me in trips to the US that
>> British voices (outside of the movies) are often subtitled,
>> while first-generation Americans whose English is. um,
>> limited, are not.
> What?!?  I've never seen a British voice (inside or outside of
> the movies) subtitled -- with the exception of one of a
> nightclub scenes in one movie (I think it was Trainspotting)
> where the dialog was inaudible because of the music.

Maybe they were dubbed? I know America International dubbed the first
version of "Mad Max" that they imported into the US. Then again,
American International is well-know for their quality.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[Mike Meyer]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Thu, 06 Oct 2005 21:03:33 -0700, barnesc wrote:
>> I added some recipes to the Python Cookbook:
>> 
>>  - listmixin
>> 
>>Use ListMixin to create custom list classes from a small subset of
>>list methods:
>> 
>>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440656
>
> That looks great. Now, if only I understood mixins: what are they, and
> what they are for, and in particular, how they differ from mere
> subclassing.

One way to look at it is that mixins are a special case of
subclassing. They aren't different, just specific.

Mixins are abstract. Using Paul's example, you'd never declare a
ScrollBar object, only subclasses that also inherit from some form of
Window.

Mixins are about behavior, not type. If you have real mixins, then an
object of a class that inherits from a mixin is not an instance of the
mixin class.

Mixins are one way to deal with the lack of multiple inheritance. But
even languages with multiple inheritance find the idea useful.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: os.access with wildcards

[Mike Meyer]

"mike" <[EMAIL PROTECTED]> writes:

> Test for the existence of one or more matches of the wildcard
> expression.
>
> For example:
>
> Are there any files that begin with 2005?
>
> This doesn't work (wish it did):
>  os.access('2005*',os.F_OK)

I would considering it suprising if it worked. os.access is for
testing access permissions of a single file. There's no reasonn for it
to do glob expansion on the name, as there can be only one such
name. Maybe if it took multiple names, but then you have to decide if
you're going to return the "or" or the "and" of the results of the
test. Or - more - likely - provide an optional argument to specify the
operation.

This is getting ugly. Best just leave it as it is.

> However, these work arounds do the job:
> glob.glob('2005*')==[]

> [Not very readable.]

Yup. A standard idiom in most languages for testing for a list to be
empty is to check the length of the list:

  len(glob.glob('2005*')) == 0

Which I'd say is more readable. In Python, an empty list is false, so
you can skip the test completely, and just ask for the boolean
negation of the list:

  not glob.glob('2005*')

I'd probably do it that way.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Matching zero only once using RE

[Mike Meyer]

"GregM" <[EMAIL PROTECTED]> writes:
> I've looked at a lot of pages on the net and still can't seem to nail
> this. Would someone more knowledgeable in regular expressions please
> provide some help to point out what I'm doing wrong?
>
> I am trying to see if a web page contains the exact text:
> You have found 0 matches

Why in the gods names are you using an re for this? Just use in:

>>> pretext1 = 'This is some text with You have found 0 matches in it'
>>> pretext2 = 'This text should not match'
>>> 'You have found 0 matches' in pretext1
True
>>> 'You have found 0 matches' in pretext2
False
>>> 

I think it's time to form a Committee for the Prevention of Regular
Expression Abuse.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:

> On Wed, 05 Oct 2005 09:38:49 +1000, Steven D'Aprano
> <[EMAIL PROTECTED]> wrote or quoted :
>
>>Yes it is. HTML means that after I've specified my email client use my
>>favourite font, in the size I like, people send me emails that over-ride
>>my choice. Invariably they use a font I don't even have. 
>
> I would suggest then a better solution is to implement CSS in email,
> the way you do in browsers to deal with that same problem.

The only way I've seen a browser fix this is to ignore the clients CSS
completely. That breaks a lot of HTML, becuase CSS has turned "tag
soup" authors into "div soup" authors.

If you've got a browser with a better solution, what's the browser,
and what's the solution?

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:

> On Tue, 04 Oct 2005 17:57:13 -, [EMAIL PROTECTED] (Gordon
> Burditt) wrote or quoted :
>
>>HTML enables a heck of a lot of problems:  "web bugs" in email,
>>links to fake sites that appear as real ones in what shows up
>>on the screen, Javascript viruses, denial-of-service attacks
>>(pages that open two windows when you close one), etc.
>>
>>>That is like hating all choirs because televangelists use them.
>>
>>I liken it more to hating all viruses because some of them 
>>install keyloggers.
>
>  I take it then you avoid browsers or use Lynx?

It's not quite that bad. You run multiple browsers: your default
browser turns off all the crap that can run code on your machine. You
use a second browser that has most of that turned on, and bookmark the
sites that need those features that you now trust. Maybe your browser
lets you have multiple profiles, in which case you can use those
instead of multiple browsers. Unless your goat browser is IE (or
Mozilla on Unix), you should keep a copy of IE (Mozilla on Unix)
around, with an untouched configuration, for the sites that either
enforce their belief that they only work on IE, or are one of those
rare sats where correctly believe that. Finally, you configure your
mail and news readers to *not* decode MIME messages unless given an
explicit command to do so.

I understand some browsers now let you enable dangers features on a
site-by-site basis. I'll check those out one of these days.

FWIW, I like w3m as a default browser, because it has the ability to
launch external browsers on a page or link.

> No you FIX the problems rather than wear a hair shirt. Same for
> email. Why should rich expressions only be permitted to those with
> websites.

The technial problems have been solved for over a decade. NeXT shipped
systems that used text/richtext, which has none of the problems that
HTML has.  The problems are *social* - you've got to arrange for
people to use mail/news readers that understand a rich text format
that isn't a vector for viruses.

> Some people use email PRIMARILY for sharing photos.

That doesn't take HTML. I get - and send - pictures via email all the
time, with nary a tag of HTML in sight.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:

> On Sat, 08 Oct 2005 17:41:38 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote
> or quoted :
>>If you've got a browser with a better solution, what's the browser,
>>and what's the solution?
> Try Opera. You can merge the two. 

Merge the two CSS files? Most browsers do that - that's why they call
them "cascading" style sheets. Got a sample style sheet that you use
that prevernts authors from overriding things?

For the font size problem, Camino has a simple solution: a "minimum
size" for fonts. That's why it's my default OS X browser (well, that
and that Terminal sucks as a scripting tool). I'm not sure you can do
that with CSS.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:
> This is one of the marvels of CSS once you get the hang of it.  If you
> don't like bright red letters on green backgrounds, you can CHANGE
> that. You can change the fonts, sizes etc etc. You can if you want get
> something very like plain ASCII text.

Show us *examples*! Do you create a style sheet for every site you
visit that overrides there classes? What?

> So from an aesthetic point of view, once people learn how it works,
> CSS lets sender and receiver compromise on what the message looks
> like. No other medium gives ANY control to the receiver about how a
> message is formatted.

Sorry, but that's bullshit. The receiver controls the viewer software,
and hence ultimately has complete control over *everything*. If I use
ghostscript as the viewer for ps and pdf files, I can install font map
files to replace all the standardd sans serif fonts with serifed
fonts, and so on. Some viewer applications may require editing the
magic .c, .cpp, etc. configuration files, but that's possible so long
as you're sending something other than pictures of words.

> There is also the philosophical question. When my nephew sends me a
> message, do I have a right to warp his intent even if I don't like the
> aesthetics?  That is part of his message.

If HTML is a medium, only someone really ignorant of the medium will
think that their presentation is preserved. As has been pointed out,
moving the file from Windows to other platforms changes the font
sizes. The physical monitor size, the screen size, the readers window
size, the dpi on the monitor, even the color depth on low-end devices
all change the presentation. The fonts you use may not be installed on
the recipients platform - I particularly like the idea that if you use
a font installed by some application, the only person who'll see it
the way you intended is the guy who bought the other copy of that
application.

So what you're really asking is if you have the right to read his
message on anything but his favorite rendering agent configured the
way he likees it, on his favorite computer configured the way he likes
it.

> Should my email reader fix the spelling mistakes in the emails sent me
> by angry US soldiers?  Or is that part of the message?

I say let Harlan Ellison decide.

> There are three different issues getting muddled together:
>
> 1. avoiding spam

I think what you mean here is "avoiding malware". Spam should be dealt
with before it gets to your mail reader.

> 2. making mail from well meaning but inept friends more readable.
>
> 3. what constitutes a good general style for general correspondence.
> How should you use rich text appropriately.

Well, if you want your presentation preserved, you don't send rich
text, you send pictures of words.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Paul Rubin  writes:
> I read mail over an ssh connection to a Unix shell.  I have no easy
> way to read html email with a graphics browser.

You don't need a grahics browser - you just need a browser. I read
mail in emacs, and use emacs-w3m to view html in the mailer. Works for
most things, and doesn't have the nasty side effect of letting the
sender know I read it by fetching images from their web site.

> I occasionally get html email that I want to read.  I save it in a
> file and read it with lynx, which so far works perfectly well.  I
> find html email to be a PITA and as someone else said, html in email
> is an almost sure sign that it's a message that I want to trash
> without reading it.

Unfortunately, I've found that HTML email comes in two flavors: That
which sets content-type to text/html in the headers, and that which
sets it to some form of multipart in the headers. I used to bounce all
mail of either form. Then I discovered that the AOL client - used by
my relatives - could *not* be set to not send HTML email. At least it
sends text/plain as well. On investigation, most legit email does
sends multipart/mixed, so I only reject mail whose sole content is
text/html.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:

> On Sun, 09 Oct 2005 04:44:25 -, [EMAIL PROTECTED] (Gordon
> Burditt) wrote or quoted :
>
>>And how do you fix the problem of unsolicited USENET articles?
>>(*ALL* of them are unsolicited to someone).  Or unsolicited
>>email?  
>
> Read my essay.
> http://mindprod.com/projects.html/mailreadernewsreader.html
>
> I talk around those problems.

Actually, you present a design that forces a solution that makes them
do what you want down their throats, never mind what they want, or
what they've been doing. It shows an amazing ignorance about the
internet and how people behave on it. Like most antispam proposals, it
won't actually stop spam, just force spammers to concentrate on
different channels. You seem to have randomly broken quoting for
people who download mail and read it offline, and for any medium
that's unreliable or doesn't reliably deliver messages "in order" -
which includes mail and news.  Virus writers will love the ability to
change peoples address books remotely. The problem of differing
character sets is technically solved. Practically, the solution
doesn't work because people implementing the software ignore the
standards. What's your server going to do when it gets messages with
characters in them that aren't valid in the charset that it's declared
as being? Better yet, what's it going to do when the characters are
valid, but the declared charset isn't the one the author actually
used? You implementation sketch only covers the client talking to the
first server (in that it requires the client to encrypt a challange
phrase with the private key belonging the email id, which is
presumably what 2822 uses for the envelope sender). Most mail on the
internet goes through at least two servers, and news is much
worse. For instance, your messages apparently passed through 10
servers getting to me. You really have to deal with store and forward,
or convince a large number of corporations that potentially hostile
users should be allowed to talk directly to their mail servers, which
isn't very likely. Kudos for recognizing that spam needs to be dealt
with by people with guns, but you lose half of them for making ISPS
liable for it.

I also read the comment about wanting an automated "Ask them to run my
browser in my favorite configuration", which is equally naive. A lot
of sites have such cruft on them already. I find them funny - I surf
the web on three different platforms, none of them Windows. Any
pointer to download a new browser or plugin for Windows just impresses
me with the authors lack of skills. The only browser I know of that
runs on all three platforms is Opera, and it's something radically
different on one of the three. Even should you get the platform right,
almost nobody is going to bother upgrading following the download
links. The very small percentage of users who are real geeks will
silently thank you for the notice, and update their software. Most
users will ignore it so long as the page isn't obviously broken. For
those for whom it's broken, all but small percentage will simply find
some other site to visit. I'd suggest that anyone thinking about writing

> It requires a fresh start.

You think you're the only person - and probably not the first - to
propose such? People a lot smarter than either of us, with a lot more
pull and a lot more reason to want it to happen have worked on this -
and it ain't happened yet. I wouldn't bet on it happening anytime
soon.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:

> On Sat, 08 Oct 2005 19:56:50 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote
> or quoted :
>
>>Show us *examples*! Do you create a style sheet for every site you
>>visit that overrides there classes? What?
>
> Why don't you download a copy of Opera, see
> http://mindprod.com/jgloss/opera.html

What makes you think I don't have a copy of Opera? Just so happens
I've got a registred copy on my newest computer.

> Then try out the feature.  Click View | style | user

My copy of Opera doesn't have that menu entry. I suspect you're making
platform-specific suggestions.

Trying it on a different platform, it looks like it does what I said
earlier: user mode simply disables the authors style sheets. None of
the "merging" you suggested was going on is actually happening

Can you demonstrate this "merging" you talked about? For example, show
me how to get the "Opera help" page to display with the authors layout
but my fonts.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:
> There is no fundamental reason that formatted spam should have an
> easier time penetrating your defenses than plain text spam.

Formatted spam can include pictures of words. That's a common spam
tactic - send a multipart/alternative with a text part that look like
a letter from aunt jane - and mention that you're sending a
picture. The picture part is basically a jpeg of a flyer for the spam
companies product.

If you've got a spam filter that can determine that a picture of words
is spam, I'd like to know about it.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

"Dr.Ruud" <[EMAIL PROTECTED]> writes:
> Let procmail make all those decisions and transformations for you.

I prefer qmail dot-commands. It provides an architecture for
controlling the delivery of email, and lets you write the smarts of
the mail processing in whatever language you want.

> I have a maildir called 'raw' where I keep a copy of all non-spammish
> mail.

I call mine archives. I also remove duplicate email before it gets to
the mailbox.

> Copies of the same messages also get delivered in the right mailboxes,
> by procmail.

Yup, qmail does that for me.

> A message that contains only html, is piped though lynx -dump -stdin.

I build a bounce message explaing that it wasn't read, and send that
back to the sender.

> A message containing both HTML and a plain/text-part, is de-mime-d,
> leaving only the plain/text-part (unless that part contains only a silly
> remark).
> Footers and long signatures are limited or even deleted. Etc., etc. (I
> like my mail cooked.)

I don't do those things. Then again - my mail reader makes deals with
them on request.

> One of the reasons that I started with Perl, is that I want to rewrite
> procmail in Perl.

Try qmail - it may solve the problem with a lot less work.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: new forum -- homework help/chit chat/easy communication

[Mike Meyer]

Lasse Vågsæther Karlsen <[EMAIL PROTECTED]> writes:

> Fredrik Lundh wrote:
> 
>> "Unlike mainstream component programming, scripts usually
>> do not introduce new components but simply "wire" existing
>> ones. Scripts can be seen as introducing behavior but no
>> new state. /.../ Of course, there is nothing to stop a
>> "scripting" language from introducing persistent state -- it
>> then simply turns into a normal programming language."
>> -- Clemens Szyperski, in "Component Software":
> 
>
> That description seems to describe whatever is written more than
> whatever it is written in, or in other words, it describes the
> difference between a script and a program, not between a scripting
> language and a programming language.

It also pretty solidly capture what a shell script does.

> I think that at one time, scripting languages was something that lived
> within other programs, like Office, and couldn't be used by themselves
> without running it inside that program, and as thus was a way to add
> minor functions and things to that program.

That's certainly one kind of scripting language. But I don't think
it's ever been the only kind - shells have always been stand-alone
applications. What they have in common with your definition is that
both types of languages are used to capture user actions for later
repetition. And that's what makes a scripting language: it's a
language in which one writes "scripts" that describe actions -
normally taken by a user - so that a series of them can be performed
automatically.

For my take on the ontology of scripting languages, see http://www.mired.org/home/mwm/scripting/what.html >.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Tim Tyler <[EMAIL PROTECTED]> writes:
> In comp.lang.java.programmer Mike Meyer <[EMAIL PROTECTED]> wrote or quoted:
>> The technial problems have been solved for over a decade. NeXT shipped
>> systems that used text/richtext, which has none of the problems that
>> HTML has.  The problems are *social* - you've got to arrange for
>> people to use mail/news readers that understand a rich text format
>> that isn't a vector for viruses.
> It's not HTML that has problems, it's Microsoft's crappy software.

HTML is a problem on *other* peoples crappy software as well. It
wasn't designed to carry code content, but has been hacked up to do
that.

> Writing virus-free HTML renderers is not hard - but of course
> Microsoft can still screw it up.

Sure - just disable all the features that make people want to use HTML
instead of something else.

> Don't blame HTML for viruses - *every* document format Microsoft has
> anything to do with becomes a vector for viruses.

Which would mean that every open format that MS has had anything to do
with comes a vector for viruses. Somehow, I'm not buying it.

And HTML has more problems than just viruses - web bugs, for one. But
MIME's support for external bodies gives you that anyway.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Tim Tyler <[EMAIL PROTECTED]> writes:
> In comp.lang.java.programmer Mike Meyer <[EMAIL PROTECTED]> wrote or quoted:
>> Roedy Green <[EMAIL PROTECTED]> writes:
>> > Read my essay.
>> > http://mindprod.com/projects.html/mailreadernewsreader.html
>> >
>> > I talk around those problems.
>> 
>> Actually, you present a design that forces a solution that makes them
>> do what you want down their throats, never mind what they want, or
>> what they've been doing. It shows an amazing ignorance about the
>> internet and how people behave on it. Like most antispam proposals, it
>> won't actually stop spam, just force spammers to concentrate on
>> different channels. You seem to have randomly broken quoting for
>> people who download mail and read it offline, and for any medium
>> that's unreliable or doesn't reliably deliver messages "in order" -
>> which includes mail and news.  Virus writers will love the ability to
>> change peoples address books remotely.
>
> Since - in Roedy's essay - messages are digitally signed, authority
> to advise about any email address updates would presumably be confined
> to those people with access to the sender's private key.

It's not confined to just people - software can do this as well. In
particular, you should expect that the users mail agent will have to
have access to the key, so it can automatically send out the change of
address notice when the user changes their address (it actually needs
it to send any mail). Viruses regularly make users mail agents do
thing. "Change my address" becomes much more entertaining when that
triggers sending out change of addresses notices to everyone in the
address book. More likely, though, there'll be an API for getting the
key so that users can change mail agents without invalidating the
public key that everyone they correspond with has for them, and the
virus will just use that API.

This is also why his plan doesn't stop spam. Most spam comes from
zombies already. This will just cause them to masquerade as the owner
of the owned machine rather than somebody the author has a beef with.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:
> Perhaps you could slow them down with some randomly chosen questions
> to prove they know something about you.  Companies could do the same
> thing.

Challenge-response system are old hat. I use one, and it reduces my
spam by three orders of magnitude. Most of what's left is spam that
went to a list that I've subscribed to whose mail circumvents the
anti-spam feature, and nigerian scam type things, which violates one
of the assumptions that such systems make about spam.

The downside is that I have no idea how many people try to contact me
out of the blue, or from an address other than the one I sent mail to,
but don't bother to answer the response. 

> You can inconvenience the sender to a fair degree since most people
> don't often write strangers with the expectation of a personal
> correspondence.

Right. Nobody sends email to addresses that come off business cards,
or off a web site, or 

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Mike Meyer]

Roedy Green <[EMAIL PROTECTED]> writes:
> On Sun, 09 Oct 2005 05:55:01 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote
> or quoted :
>>Virus writers will love the ability to
>>change peoples address books remotely.
> Since this is just a broad brush view, I find it odd you can predict
> just what bugs there will be in the early implementations.

I'm not predicting bugs in the implementations. I'm predicting how
people are going to abuse *features* of the implementations.

> You sound almost as if you were the author of the current system and
> feel personally attacked by others looking for ways to improve it.

Nah, I've just know people who spend a lot of time - and money -
dealing with spam, and we've discussed these issues at great
length. You haven't proposed anything that hasn't been proposed
before, and rejected for various reasons.

> In my scheme, every message is digitally signed, even a change of
> address message. 

Yup, I assumed that.

> Surely for a virus to send out a digitally signed change of address
> message is more difficult than sending out an unsigned one, which they
> can do today.

Maybe yes, maybe no. They can use existing APIs to send mail now. If
there's an API to sign a message - and there just about has to be,
otherwise changing mail readers will require sending out a change of
address form to change the public key - what prevents the virus from
simply using that to send out an encrpyted message? Yes, it's more
difficult, just like it's more difficult to send out mail with an
attachment than one that's just plain text. But the difference is just
more work, not something fundamentally different.

> You have two problems you want to avoid:
>
> 1. the practical problem:  failure to inform your correspondents, not
> just your address list, of your new address (at least the ones you
> don't consider spam or pests).
>
> 2. the potential problem:  rogue software sending out fake change of
> address notices.
>
> In my scheme, The receiver of the change of address  message ignores
> it unless it is properly signed.  Surely that is a more secure system
> than we have today and that handles (1) without effort.  At worst, a
> very clever virus could change the one address book entry, the one for
> this computer, in other's machines.   It could not generally corrupt
> other machines.

Depends on how convenient you make things. The problems aren't
technical, they're social. For instance, people will want their
address book to automatically send out change of address notices to
every non-pest if their address is changed. A virus can exploit this
by changing the address in the address book. No need for it to send
out mail - the users mail agent does it all for them. Fixing this
requires convincing the users that they should do a lot of work to
achieve point 1 - which sort of defeats your purpose.

Personally, I don't believe that you'll convince people to take do
more work to get more security. So you've got to convince all the
authors who deploy mail readers - and/or key security systems - to not
allow that. Since such a feature will be requested by users, and will
make their software more popular, that's not going to be easy either.

To be really secure, you store the private key encrypted, and ask the
user for a passphrase to decrypt it every time you want to sign a
message. So you make your interface do that, and it asks the user for
a key every time a message is signed. For true security, you have to
include the recipient address in the signatture, otherwise you're
liable to replay attacks sent different addresses, so changing your
address will involve providing your pass phrase once for everyone you
notify. Someone else will decide that's to inconvenient, and provide
an interface that stores the passphrase to reuse for some
user-specified length of time. Existing systems do this, and get lots
of use even thought they are less secure than doing it right. Then
you'll get a interface that ask for the key once a session. Then
you'll get one that asks once, and just keeps it forever. We've seen
this happen with access to web site passwords.

Guess which one users are going to prefer. Guess which one makes it
simple for viruses to hijack they system to send out mail that "you"
have signed.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: searching a project to contribute to

[Mike Meyer]

"Clint Norton" <[EMAIL PROTECTED]> writes:
> Hi all,
> I'm a student currently in the beginning of my master's degree and
> I'm searching for an interesting open source project written in Python
> to contribute to.
> I have worked as a programmer for the past few years (mostly in
> academia but also as a typical full time code monkey in a commercial
> company), some of it in python, some in Java (commercial companies
> really seem to like Java).
> Anyway, which python projects would be a good start? I generally
> like working on algorithmic parts or "Business Logic" and really don't
> like doing interface work. The software I like producing has a tendency
> to make use of the random and/or math modules, if that says something
> about the nature of the work I've done... I really want to give
> something back to the community I've taken so much from in the past.

Well, if there's some software you use on a regular basis, that's a
good start. Python itself is a candidate. If the goal is just to
contribute, start going through the bugs database, and see if you can
contribute patches that fix some of the reporrted bugs.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list