From mhammond@skippinet.com.au  Fri Oct  1 01:27:03 1999
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Fri, 1 Oct 1999 10:27:03 +1000
Subject: [Python-Dev] getopt helper?
In-Reply-To: <14323.51267.54862.538939@anthem.cnri.reston.va.us>
Message-ID: <001601bf0ba3$b06ad770$0801a8c0@bobcat>

OK - general agreement.  Wheee :-)

How about this:

def getopt_or_die(opts,
                  long_opts=[],
                  usage=None,
                  prog_name=None,
                  args=None,
                  exit_code = 1):

if usage is None, we build a very simple usage string from
opts/long_opts.

If prog_name is None, we use os.path.basename(sys.argv[0]).  This is
printed just before the usage message.

If args is None, we use sys.argv[1:]

exit_code specifies the param to sys.exit() on invalid options.

I have based the ordering on my guess at the most likely to be used -
but maybe "prog_name" and "args" should be reversed?  This should
_not_ be all-singing, all-dancing, as it is simple to use the existing
getopt.getopt() directly for more esoteric requirements; the old 80-20
rule applies here :-)

If the general agreement continues, I will then knock together an
implementation.

Mark.



From gward@cnri.reston.va.us  Fri Oct  1 01:51:37 1999
From: gward@cnri.reston.va.us (Greg Ward)
Date: Thu, 30 Sep 1999 20:51:37 -0400
Subject: [Python-Dev] getopt helper?
In-Reply-To: <001601bf0ba3$b06ad770$0801a8c0@bobcat>; from Mark Hammond on Fri, Oct 01, 1999 at 10:27:03AM +1000
References: <14323.51267.54862.538939@anthem.cnri.reston.va.us> <001601bf0ba3$b06ad770$0801a8c0@bobcat>
Message-ID: <19990930205136.A14297@cnri.reston.va.us>

On 01 October 1999, Mark Hammond said:
> OK - general agreement.  Wheee :-)
> 
> How about this:
> 
> def getopt_or_die(opts,
>                   long_opts=[],
>                   usage=None,
>                   prog_name=None,
>                   args=None,
>                   exit_code = 1):
> 
> if usage is None, we build a very simple usage string from
> opts/long_opts.

I still think it would be very desirable to tie the short and long
options together.  Eg.

  options = [('verbose', 'v'),
             ('quiet', 'q'),
             ('thingy', None),
             (None, 'x')
             ('output=', 'o:')]
  opts, args = getopt_or_die (options, usage, ...)

Then opts would have possible keys 'verbose', 'quiet', 'thingy', 'x',
and 'value' -- never 'v', 'q', or 'o'

(Look, I restrained my tendency to invent type systems and auto-generate
help text.  There may be hope for me yet.)

        Greg


From tim_one@email.msn.com  Fri Oct  1 06:55:46 1999
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 1 Oct 1999 01:55:46 -0400
Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports)
In-Reply-To: <199909181417.PAA20866@pukapuka.inrialpes.fr>
Message-ID: <000101bf0bd1$9b1cf5a0$842d153f@tim>

[Vladimir Marangozov, plugging]
> Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating
> Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978.

Wasn't Saltzer one of the CNRI fellows' advisors?  Jeremy's, perhaps?

it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs  - tim




From mhammond@skippinet.com.au  Sun Oct  3 08:52:59 1999
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sun, 3 Oct 1999 17:52:59 +1000
Subject: [Python-Dev] getopt helper?
In-Reply-To: <19990930205136.A14297@cnri.reston.va.us>
Message-ID: <001a01bf0d74$5031ed80$0801a8c0@bobcat>

Greg writes:
> I still think it would be very desirable to tie the short and long
> options together.  Eg.
>
>   options = [('verbose', 'v'),
>              ('quiet', 'q'),
>              ('thingy', None),
>              (None, 'x')
>              ('output=', 'o:')]
>   opts, args = getopt_or_die (options, usage, ...)
>

Im not convinced this is worth it.  I only use "long options" when I
have too many, or a few obscure ones.  I have never have "-v"
synonymous for "--verbose" - why bother?  I know I would never type
the later:-)

The existing mechanism still handles this quite well - the standard
"if opt==blah:" simply becomes "if opt in [...]:" - no real drag.

Plus its less change for reasonable reward - handy enough I may
actually add command-line handling as I create each little test/util
script :-)

What say anyone else?  Go with my "little change", Gregs "only
slightly more change" or "don't worry about it"?

Mark.



From skip@mojam.com (Skip Montanaro)  Sun Oct  3 15:26:54 1999
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Sun, 3 Oct 1999 09:26:54 -0500 (CDT)
Subject: [Python-Dev] getopt helper?
In-Reply-To: <001a01bf0d74$5031ed80$0801a8c0@bobcat>
References: <19990930205136.A14297@cnri.reston.va.us>
 <001a01bf0d74$5031ed80$0801a8c0@bobcat>
Message-ID: <14327.26542.101415.144270@dolphin.mojam.com>

    Mark> Im not convinced this [pairing up long and short options] is worth
    Mark> it.

The primary reason where it would be helpful is to generate clearer default
usage strings.  Aside from that, I'm not sure the extra structure would be
worth it.

Skip


From jeremy@cnri.reston.va.us  Sun Oct  3 18:05:18 1999
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Sun, 3 Oct 1999 13:05:18 -0400 (EDT)
Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports)
In-Reply-To: <000101bf0bd1$9b1cf5a0$842d153f@tim>
References: <199909181417.PAA20866@pukapuka.inrialpes.fr>
 <000101bf0bd1$9b1cf5a0$842d153f@tim>
Message-ID: <14327.36046.4763.670777@bitdiddle.cnri.reston.va.us>

>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:

  TP> [Vladimir Marangozov, plugging]
  >> Saltzer J., "Naming and Binding of Objects", in Bayer R.,
  >> "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60,
  >> 1978.

  TP> Wasn't Saltzer one of the CNRI fellows' advisors?  Jeremy's,
  TP> perhaps?

Indeed he was.

  TP> it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim

I think sixth degrees of separation only made sense in the pre-email
world.  These days it's probably down to four or five.

Jeremy




From mhammond@skippinet.com.au  Mon Oct  4 00:30:25 1999
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Mon, 4 Oct 1999 09:30:25 +1000
Subject: [Python-Dev] ESR on slashdot
Message-ID: <002001bf0df7$45e964b0$0801a8c0@bobcat>

Just as a matter of interest, here is a question put to ESR and his
answer.  We certainly could do alot worse than to have ESR becoming a
real Python advocate :-)  If only Guido himself could find time to
work on 1.6, we would be "in like Flynn" :-)

Mark.

shawnhargreaves asks:
You've always been involved in hacker projects outside of just coding
(eg. the Jargon File), but over the last year or so the spokesperson
role seems to have grown into a fulltime job. How long is it since you
last sat down to write a major piece of software? Do you expect to go
back to fulltime development work anytime soon, and if so, what would
you work on? How do you manage to cope with the withdrawal symptoms?

ESR answers:
An astute question ;-). I haven't sat down to write a major piece of
software from scratch in months, but I am continuing to maintain
fetchmail. I just took over the gif2png beta code with Greg Roelofs's
consent; the 1.0.0 version might be out by the time you read this.
Today I did some work on gnuplot, bringing the PNG driver up to date.

If I get to go full-time again soon, I want to go back to work on
Trove, the distributed web-based code-archiving system I designed last
year. I'd also like to work with Guido van Rossum on Python 1.6; there
are some long-time wishlist features like rich comparisons and a full
lambda facility that I care enough about to implement myself. I also
have a strategy-gaming system I wrote back in the 1980s that I'd like
to put a modern (Web-based) interface on. Finally, having contributed
a bit of code to GNOME (the network-monitor applet) I'd like to
balance things by doing something for KDE.



From gstein@lyra.org  Mon Oct  4 10:51:53 1999
From: gstein@lyra.org (Greg Stein)
Date: Mon, 4 Oct 1999 02:51:53 -0700 (PDT)
Subject: [Python-Dev] Alternative Approach to Relative Imports
In-Reply-To: <37F21B2F.DD65738F@interet.com>
Message-ID: <Pine.LNX.4.10.9910040248120.27657-100000@nebula.lyra.org>

On Wed, 29 Sep 1999, James C. Ahlstrom wrote:
> "M.-A. Lemburg" wrote:
> > I know, but there still is no way to query what kind of hooks
> > are already loaded and what is worse, you cannot unload or reorder
> > them.
> 
> I think this is a valid point.  I am interested in hooks to read
> modules from a file archive.  If you are a developer, it is
> necessary to turn this hook OFF, so that you can revert to the
> usual directory tree where your current source is.
> 
> I am solving this by leaving a global variable "Importer" in
> sitecustomize, and calling sitecustomize.Importer.enable(0).
> This works, but it might be useful if imputil could de-install
> a hook as well as install it.

It was a design point to not provide this functionality. It is pretty
difficult to unhook the importers from the chain. I specifically said,
"well... when you alter the import behavior, then it will stay that way."

I figured this was entirely safe since an Importer could have an
enable/disable flag like you implemented, or my (theoretical) Import
Manager could pull an Importer out of its list that it was managing.

I'm not sure that we want an Import Manager to always be installed in the
hooks, but it could be a good idea to have a standard manager in the
library somewhere (which Importers could state a dependency upon its
installation).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/




From jim@interet.com  Mon Oct  4 16:16:28 1999
From: jim@interet.com (James C. Ahlstrom)
Date: Mon, 04 Oct 1999 11:16:28 -0400
Subject: [Python-Dev] Alternative Approach to Relative Imports
References: <Pine.LNX.4.10.9910040248120.27657-100000@nebula.lyra.org>
Message-ID: <37F8C4CC.6C230B06@interet.com>

Greg Stein wrote:

> It was a design point to not provide this functionality. It is pretty
> difficult to unhook the importers from the chain. I specifically said,
> "well... when you alter the import behavior, then it will stay that way."
> 
> I figured this was entirely safe since an Importer could have an
> enable/disable flag like you implemented, or my (theoretical) Import
> Manager could pull an Importer out of its list that it was managing.

I think my design of leaving a global "Importer" instance variable
in imputil is a bit lame.  Each importer is a class instance, but I
don't see a list of importers in imputil.

Suppose impuil kept a list of installed importers
imputil.ImporterList[].
Then to access an importer I have installed, I can write:
    for im in imputil.ImporterList:
      if isinstance(im, MyImporter):
        im.enable(0)
It would not be necessary to dis-install an importer, imputil would
just undertake to keep a list of installed importers, and if someone
wanted to control their installed importers, they would use the list.

I do not feel too strongly about this.  Maybe it is a good idea.
What do you think?  I can just use my global variable I guess.

Jim Ahlstrom


From fredrik@pythonware.com  Wed Oct  6 10:52:55 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 6 Oct 1999 11:52:55 +0200
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
Message-ID: <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com>

http://www.cobolscript.com/

    "[COBOL's] just a language whose superiority for
    developing certain types of modern systems has
    been overlooked until now"

    PROCEDURE DIVISION.
           0000-MAIN.
           DISPLAY WEB-PAGE-HEADER.
           ACCEPT DATA FROM WEBPAGE.
           COMPUTE grand_total = subtotal *(1  sales_tax_rate).
           DISPLAY WEB-PAGE-BODY.
           DISPLAY WEB-PAGE-FOOTER.

well, why not? :-)

</F>



From jack@oratrix.nl  Wed Oct  6 12:02:39 1999
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 06 Oct 1999 13:02:39 +0200
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: Message by "Fredrik Lundh" <fredrik@pythonware.com> ,
 Wed, 6 Oct 1999 11:52:55 +0200 , <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com>
Message-ID: <19991006110240.068AC35BB1E@snelboot.oratrix.nl>

> http://www.cobolscript.com/
> 
>     "[COBOL's] just a language whose superiority for
>     developing certain types of modern systems has
>     been overlooked until now"

The whole site sort-of makes me wonder whether this is one big elaborate joke. 
But if it is somebody put an incredible amount of work in it.

The funny thing is that the idea of using Cobol for web-programming _did_ 
initially strike me as a neat idea: because of the elaborate data descriptions 
and report generation facilities you could conceivably use all that info to 
automatically generate all the input forms and such. But they have apparently 
done no such thing...

The timesheet example is, uhm, interesting. 1500 lines of code, with many 
parameters hardcoded in the source. I'd be surprised if it would take more 
than 100 lines in Python, with a lot more customizability too.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From guido@CNRI.Reston.VA.US  Wed Oct  6 15:57:21 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 06 Oct 1999 10:57:21 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: Your message of "Wed, 06 Oct 1999 13:02:39 +0200."
 <19991006110240.068AC35BB1E@snelboot.oratrix.nl>
References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl>
Message-ID: <199910061457.KAA08749@eric.cnri.reston.va.us>

> X-Last-Band-Seen: Raggende Mannen afscheidsconcert (Paradiso, 4-10)
> X-Mini-Review: IK HEB HET OVERLEEFD! IK HEB HET OVERLEEFD! IK HEB HET 
>     OVERLEEFD!

Ach!  Wish I was there!

> > http://www.cobolscript.com/
> > 
> >     "[COBOL's] just a language whose superiority for
> >     developing certain types of modern systems has
> >     been overlooked until now"

> The whole site sort-of makes me wonder whether this is one big
> elaborate joke.  But if it is somebody put an incredible amount of
> work in it.

Definitely a joke.  Try

http://www.cobolscript.com/csfaq.htm#question9

"One of the other advantages of COBOL is that COBOL file processing
statements are very simple, with no knowledge of disk head positioning
required."

But yes, an incredibly good one!  Worth filling out the form on the
"contact us page" and seeing what they send back.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From gmcm@hypernet.com  Wed Oct  6 17:55:18 1999
From: gmcm@hypernet.com (Gordon McMillan)
Date: Wed, 6 Oct 1999 12:55:18 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: <199910061457.KAA08749@eric.cnri.reston.va.us>
References: Your message of "Wed, 06 Oct 1999 13:02:39 +0200."             <19991006110240.068AC35BB1E@snelboot.oratrix.nl>
Message-ID: <1272894334-31005071@hypernet.com>

[Guido, on http://www.cobolscript.com/]

> Definitely a joke.  Try
> 
> http://www.cobolscript.com/csfaq.htm#question9
> 
> "One of the other advantages of COBOL is that COBOL file
> processing statements are very simple, with no knowledge of disk
> head positioning required."
> 
> But yes, an incredibly good one!  Worth filling out the form on
> the "contact us page" and seeing what they send back.

While funny, I can virtually guaruntee these people are serious.

It is a common misperception among mainframe/COBOL 
types that C/Unix has *only* character I/O (which does not 
exist in the former environment at all - even terminals are 
block I/O). They regard this as a sign of their vast superiority. 
(And I dearly wish that born-again "Windoze" bashers be 
sentenced to work in this environment - they'll soon realize 
how closely related Windows and Unix are).

I did a number of stints introducing client / server to Big Blue 
shops. (Unix made it's entry *only* because RDBMS's ran on 
them, and all these shops claimed they would dump Unix as 
soon as these products worked right on big iron). I *always* 
had an endless fight with the people who wanted to use 
COBOL instead of C / C++ (on both the Unix boxes and the 
PCs). 

MicroFocus distributed a "white paper" comparing COBOL to 
C that I came to know very, very well. It came in 4 sections:
- the Executive Summary said COBOL was vastly superior in 
all respects
- the White Paper said COBOL was more maintainable 
(translation - you can hire brown-nosing dorks in suits, instead 
of geeks in T-shirts) and often had superior performance
- the Benchmark showed that C smoked COBOL in absolutely 
everything except binary search (a COBOL builtin)
- the Appendix showed that the C code for "binary search" 
was a very badly coded linear search.

But no shop had ever read past the Executive Summary.

And don't forget that there is probably more than one order-of-
magnitude more COBOL source out there than source in any 
other (or maybe all other) language(s). All with no built-in date 
type; and hardly ever using common date routines either 
(calling external programs in COBOL is expensive, and 
awkward, because all variables are global).

Y2K-compliant-by-omission-ly y'rs

- Gordon


From guido@CNRI.Reston.VA.US  Wed Oct  6 18:00:50 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 06 Oct 1999 13:00:50 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: Your message of "Wed, 06 Oct 1999 10:57:21 EDT."
 <199910061457.KAA08749@eric.cnri.reston.va.us>
References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl>
 <199910061457.KAA08749@eric.cnri.reston.va.us>
Message-ID: <199910061700.NAA09211@eric.cnri.reston.va.us>

Now I'm confused...  I typed in the comment box:

	Very good joke.  ROFL.
	Where do you guys find the
	time and energy to do this!
	:-)

and got this back:

	Mr. van Rossum

	Glad you took the time out of your busy schedule to berate us.
	We must be doing something right! ;)

	Chuck Shereda
	Deskware, Inc.
	www.deskware.com
	www.cobolscript.com

--Guido van Rossum (home page: http://www.python.org/~guido/)


From klm@digicool.com  Wed Oct  6 18:19:30 1999
From: klm@digicool.com (klm)
Date: Wed, 6 Oct 1999 13:19:30 -0400 (EDT)
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: <199910061700.NAA09211@eric.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.9910061316460.3705-100000@korak.digicool.com>

On Wed, 6 Oct 1999, Guido van Rossum wrote:

> Now I'm confused...  I typed in the comment box:
> 
> [...]
> and got this back:
> 
>       Mr. van Rossum
> 
>       Glad you took the time out of your busy schedule to berate us.
>       We must be doing something right! ;)
> 
>       Chuck Shereda
>       Deskware, Inc.
>       www.deskware.com
>       www.cobolscript.com
 
Apparently deskware is a known, bona fide organization.  Considering the
massive number of cobol programmers around, and despite how cumbersome the
prospect is (and with the advantage of factoring in the things gordon
said), i guess someone thinks there's leverage in making cobol a scripting
language.  I think it's not so different than making interpreted versions
of C (but i'm not very C friendly).

Ken
klm@digicool.com



From klm@digicool.com  Wed Oct  6 19:05:21 1999
From: klm@digicool.com (Ken Manheimer)
Date: Wed, 6 Oct 1999 14:05:21 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
Message-ID: <613145F79272D211914B0020AFF640191D1D2D@gandalf.digicool.com>

Concerning the possibility of cobolscript, i wrote:
 
> said), i guess someone thinks there's leverage in making cobol a
scripting
> language.  I think it's not so different than making interpreted
versions
> of C (but i'm not very C friendly).

After posting i thought this might come off as more ignorantly bigoted
than i meant for it to seem:-)  I was trying to say that C doesn't seem
very well suited to scripting/running interpreted, like cobol - not that
C is as fraught with ancient and awkward design as cobol (seems).

Sigh.

Ken
klm@digicool.com


From mal@lemburg.com  Mon Oct 11 21:36:07 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 11 Oct 1999 22:36:07 +0200
Subject: [Python-Dev] Walking up the package hierarchy
Message-ID: <38024A37.D92E7091@lemburg.com>

This is a multi-part message in MIME format.
--------------8F8110B6CFB57E279F385677
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi everybody,

while I'm still thinking about writing the import manager, here
is a patch that implements the walk-up-the-hierarchy import scheme
that got so much positive feedback. I'm intending to use this
implementation as proof of concept for the switch to my new
package structure, but wouldn't mind seeing something like it
the distribution as well ;-)

It changes the default import mechanism to work like this:

>>> import d
try a.b.c.d
try a.b.d
try a.d
try d
fail

instead of just doing the current two-level lookup:

>>> import d
try a.b.c.d
try d
fail

As a result, relative imports referring to higher level packages
work out of the box without any ugly underscores in the import name.
Plus the whole scheme is pretty simple to explain and straightforward.

Since the patch is so small, I attached it to this mail. Hope
you don't mind. The ZIP archive also contains a sample package
which demonstrates the feature. Run Python with -v flag to see how
the new scheme works.

Feedback is most welcome. I am especially interested whether the
scheme breaks any existing packages.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    81 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
--------------8F8110B6CFB57E279F385677
Content-Type: application/x-zip-compressed;
 name="walkingimport.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="walkingimport.zip"

UEsDBAoAAgAAAASgKiejNvGqNwAAADcAAAANABUAYS9fX2luaXRfXy5weVVUCQADJ0fZN/ND
AjhVeAQA9AFkAApwcmludCAnSW5pdCBtb2R1bGUgJXMsIHBhdGg9JXMnICUgKF9fbmFtZV9f
LF9fcGF0aF9fKQpQSwMEFAACAAgADq4vJ7lAUhN3AAAA1QAAAAcAFQBhL2FiLnB5VVQJAAMM
+N8380MCOFV4BAD0AWQAjc5BCsMgEIXh/ZxiNmE0SG7QA/QMpQyaShFGDWoXIeTuXWhW3XQ3
8H4+BrYSUkO6p9Aw5tdHPE6VcELFnGz0zBogxC2Xhg7gLdlZqXhDyWs/jhM6wtw7ZkV2cWRG
bHpqHk89yjFc2rKKt0Xpfx2a6Ye6fqx7hS9QSwMEFAACAAgAGp8vJzpfQHVJAAAASgAAAA8A
FQBhL2IvX19pbml0X18ucHlVVAkAA+Td3zfzQwI4VXgEAPQBZAAVyEsKgCAUBdD5W8WdiAVO
WoALaBUXQyPBH/raf3SGR8bMTWHPlhW1x7ckmOUwgj7eLAuDjWyhJtKRf5O7SOkhpsh79soL
Hod8UEsDBBQAAgAIALKtSyehIXVYrAAAAEsBAAAJABUAYS9iL2JjLnB5VVQJAANfPgI480MC
OFV4BAD0AWQAbc5BDoIwEAXQfU/xgyGoix7AxAO4caVxSQYYgdh2TFsk3l5UMBFdzeL/lz/q
6lsXke1cG2Gl6gwjDRlSLPPckeU8Xyk1lg7+3roarb2Kj5DzBKjAdgvSw9VaZ2osUPGRJ0Zo
pDMVnPRo6DagsuQQEAUTe3efaoG9eEsGXaCa0b9kwRt19mJB+B04hudnyTxP0DNqjvOBP0rC
xNbfap6O2EhJJixX+sL34Sj1AFBLAwQUAAAACACmsEsnju+MVhAGAACcEAAAEwAVAHdhbGtp
bmdpbXBvcnQucGF0Y2hVVAkAA/dCAjj3QgI4VXgEAPQBZACNV3tv00gQ/9v9FENOR5M6zqNQ
ShIFUR3tgQSlAg5OgpO1STaJr37den0lOvW738zOruO8oFFV27szs/P4zWODIICblV5maTdK
8kzpztS7UhFc5ApgAP3BsNcbnvXxZTA48n0fussskd1YJpNSLbq50NOlnHVZRNDvnHVOff9O
xLdRumCB3W3x77IU3k819PtwejrsPR32zlj8y5cQ9M+e9dunffD55Tng4kLqMBdKprq5iLOJ
iIs2TMp5G/IQH7FMW0dwfwRHUGihoyna837yt8QTTo4gzsQsTOV33UyyWRtErM0zD1ORyF0x
3poX6UZHQW2BeUfQPYHLSC+lgusslZApKFAWiAJwG066R/5+putMQ1nIGYh0lWRKdogWvOlS
KDg5YY1G1QKqRB9RikKcgrjwX0VA5DCGHcYZHjNGV6jpUjXZyuPOccsJYzGWNh9tmKxkUcYa
19AEVPhTBom4lRB8EXEMS5Hnq06nwxayXXiQcZOPK9Ecmjer8LNUk6yQV7FYtHDVyxWeOm82
flmHYgjNfgtItfHxr8UxRkEU0n52Torjb2mjTazAP2ND5YM2Plp0IpgTjbVjuP7j7duWcY5n
HQK8SAZ6yMYuwRfjEuMNhIwn40IiGyPv+bP20zNC3uBJe3BOyHsoeuiQm9WlUuFHqT9qNHmB
vrj8Pg0/i7iUuJGpNhF5XuMyyfWK3FbG0tjWMNp4SupSpZXSBOjAy1FvPAX8OggCY3kOj8xe
C7/RaEzNMQW62vaRNiDeF2N4d/HnzcWn128vr8lJwUOUDYyy79Zqgs4ydEi6IH2DLX0D1Dfw
0MPpNF818zYHjcBmiPOv+PYXKfitZzSsrMG1SlPcwC0GIa5zwQiLcsLO4hjkxu0tZ6ajHmPW
hyYfHz+2cSL/4KOyOHx1+duHyyvLwkYgyl9LJV1oISkLDRPJmS3SGVSLabbewAwwDjikaIUT
/ONzaqo+YmCSnusVq7zV1ZAnQt2GSVQUTbKXiHq07Xt3ywhDQilEXyapXQKF7NEaVigzycqL
PJdoDpYtaBKgW3UEQo7BNXvzEjPdLEWpTUGCkEn5/WD0vS004sIGHB3BYTwSx88BSVQ/QCRt
b0ASF+7p3wFQkj2bqPS9Q7D0nRF76tuBAnfasrCAChbAxa5huGxta5DDq0roCp/bzatix0H8
IuHNNWHYwBI7ELmAa3RR4kekqQWuChAqKzHas5J8SYG1sVzrYrsxfFpGBZb2ggQhvGcE7yJK
pxLuHBNyRHNTseAO+15WagTHVMkEG7IVj0iewxTP1A40Ms7ubKug1GO1KYPZ9Q9Ncr+euI7b
RWMn9y2YrPdcz52TL6hxUUYZbSmr2tQPopxRH6UiRtu1ljPnfwOwucoSQ+ESzNQEhJlaOa8S
rY200IaWEADLaEETQi6mt2IhEXP/yriKLSqvTfTQ96j2CDL6vIsKROdcRLHxMx7l6CVlgPMm
FwcubzW7TXPZU+R8TpxD6D2E3yctU/GM7yCwoF3D1k54ULIDl5FUAgeOFSKYo7Y+9WAdO6Sw
2dhOZZvMLHKj3L2oy8MjvtZ3N7Ibf9VwZKYj0795OKofQUPBBn1Ni+2Zw9LVC0dvtCOmvk3c
AXBdcSpX+1v60mlr3hebnqsNqpg4hWWx23YRCCNvOMd+l5qL56toqpuVpy2cmHrTqj1R8Hjq
u1mREBL5RsvE1mwrxZVqz7WP7aPqA5sl3S7/bp3hxs3g46rAsza6gd1v3JjbgWtpBLZo3RX2
23F/KOTOQJNZTM1Edlb0f4RbtuMqU4nQtoex9zfUZqWvs3oPnsGvndNer2hwm+KZcGcq9Myc
tW5qBsGbsxYjamve2oSgvQMYWfc7gxQjYGfCOzRw/XC++pk/ggd7Y1sf3wZkn+77ZoEqwhMl
xa2bsMHRVVcfWjXXgfP+oN3v4XXg/Px5u/+UrgP7mxV+cgRcL28Zwdh9Psh/ykjJIX5x1Xfg
R7cNHR8tOE4mJFWHRNsJzUUjDHHkanQa+H8/DzWGh9zAtvWvdLD3sL3DiC35zsrKyJGxks5s
Jj+rCGvXtNz8i7ABvjZVw8H2rex/UEsBAhYDCgACAAAABKAqJ6M28ao3AAAANwAAAA0ADQAA
AAAAAQAAAKSBAAAAAGEvX19pbml0X18ucHlVVAUAAydH2TdVeAAAUEsBAhYDFAACAAgADq4v
J7lAUhN3AAAA1QAAAAcADQAAAAAAAQAAAKSBdwAAAGEvYWIucHlVVAUAAwz43zdVeAAAUEsB
AhYDFAACAAgAGp8vJzpfQHVJAAAASgAAAA8ADQAAAAAAAQAAAKSBKAEAAGEvYi9fX2luaXRf
Xy5weVVUBQAD5N3fN1V4AABQSwECFgMUAAIACACyrUsnoSF1WKwAAABLAQAACQANAAAAAAAB
AAAApIGzAQAAYS9iL2JjLnB5VVQFAANfPgI4VXgAAFBLAQIWAxQAAAAIAKawSyeO74xWEAYA
AJwQAAATAA0AAAAAAAEAAACkgZsCAAB3YWxraW5naW1wb3J0LnBhdGNoVVQFAAP3QgI4VXgA
AFBLBQYAAAAABQAFAGYBAADxCAAAAAA=
--------------8F8110B6CFB57E279F385677--




From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Oct 12 21:21:02 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Tue, 12 Oct 1999 16:21:02 -0400 (EDT)
Subject: [Python-Dev] string methods branch
Message-ID: <14339.38958.882650.342925@anthem.cnri.reston.va.us>

Guido has agreed to let me mainline the string methods branch.  Those
of you on python-checkins should have seen the CVS messages by now.
This is a good thing because I think we can all agree we hate CVS
branches.  For me, that final merge put the nail in the coffin.

Anyway, those of you who have put off playing with string methods
until now should just be able to do a CVS update, rebuild, and go.
You should read the revision log messages for the branch checkins for
details of the changes.  Let me know if you have any problems.  Fred
and I will work out changes to the documentation some time soon.

>>> sig=['branches','are','only','useful','for','trees','and','streams','ly']
>>> print '-'.join(sig) + " y'rs"

-Barry


From skip@mojam.com (Skip Montanaro)  Tue Oct 12 22:03:13 1999
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 12 Oct 1999 16:03:13 -0500
Subject: [Python-Dev] new opportunities for obfuscation... ;-)
Message-ID: <199910122103.QAA31864@dolphin.mojam.com>

Barry's note prompted me to update my Python tree.  The result:

    >>> ".".join(dir(""))
    'capitalize.count.endswith.find.index.join.lower.lstrip.replace.rfind.rindex.rstrip.split.startswith.strip.swapcase.translate.upper'

A job well done, Barry...

Skip Montanaro | http://www.mojam.com/
skip@mojam.com | http://www.musi-cal.com/
847-971-7098   | Python: Programming the way Guido indented...


From mal@lemburg.com  Wed Oct 13 13:27:57 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 13 Oct 1999 14:27:57 +0200
Subject: [Python-Dev] Walking up the package hierarchy
References: <38024A37.D92E7091@lemburg.com>
Message-ID: <38047ACD.E716154E@lemburg.com>

Strange... I would have thought that this new patch would stir up
some cheers or opposition. Has anyone tried it in some real apps ?

It would be interesting to see whether it breaks any code in e.g.
packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't
break anything for my packages or apps.

> It changes the default import mechanism to work like this:
> 
> >>> import d
> try a.b.c.d
> try a.b.d
> try a.d
> try d
> fail
> 
> instead of just doing the current two-level lookup:
> 
> >>> import d
> try a.b.c.d
> try d
> fail

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    79 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From Vladimir.Marangozov@inrialpes.fr  Thu Oct 14 12:26:11 1999
From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov)
Date: Thu, 14 Oct 1999 12:26:11 +0100 (NFT)
Subject: [Python-Dev] Walking up the package hierarchy
In-Reply-To: <38047ACD.E716154E@lemburg.com> from "M.-A. Lemburg" at "Oct 13, 99 02:27:57 pm"
Message-ID: <199910141126.MAA32650@pukapuka.inrialpes.fr>

M.-A. Lemburg wrote:
> 
> Strange... I would have thought that this new patch would stir up
> some cheers or opposition. Has anyone tried it in some real apps ?

Not yet, but this looks better as a default search path.

> 
> It would be interesting to see whether it breaks any code in e.g.
> packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't
> break anything for my packages or apps.

JimF, /F, Guido and other package maintainers could do you a favor
by trying your patch ;-) and give us some real feedback on this.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252


From tim_one@email.msn.com  Fri Oct 15 08:21:15 1999
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 15 Oct 1999 03:21:15 -0400
Subject: [Python-Dev] Corporate installations
Message-ID: <000401bf16dd$def75d80$d72d153f@tim>

Python is getting used widely enough in my place of employment that people
are agitating for a common installation (personal variants are screwing
people too often).  Various machines are running Win95, Win98, NT,
Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS.  I'll choke
on that whole banana when it's shoved down my throat.

For starters, I just need to get it running across Windows platforms.  Never
looked into this before, and it seems to be exceedingly complicated right
out of the box <0.5 wink>:

D:\Python>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
['',
 'D:\\Python\\win32',
 'D:\\Python\\win32\\lib',
 'D:\\Python',
 'D:\\Python\\Pythonwin',
 'D:\\Python\\Lib\\plat-win',
 'D:\\Python\\Lib',
 'D:\\Python\\DLLs',
 'D:\\Python\\Lib\\lib-tk',
 'D:\\PYTHON\\DLLs',
 'D:\\PYTHON\\lib',
 'D:\\PYTHON\\lib\\plat-win',
 'D:\\PYTHON\\lib\\lib-tk',
 'D:\\PYTHON']
>>>

Where does all that stuff come from?  The first is apparently the current
directory; cool.  The next 4 appear to come from MarkH's stuff, via the
registry.  The next 4 appear to come from Python's own registry PythonPath
key.  The 4 after that are a mystery, and duplicate the preceding 4 (except
for meaningless-- it's Windows <wink> -- case differences).  The last is
another mystery.  site.py isn't implicated in any of them (same thing when
running with -S).  I suppose this is a clue:

D:\Python>set PYTHONHOME=ick;fooey

D:\Python>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
>>> sys.path
['',
 'D:\\Python\\win32',
 'D:\\Python\\win32\\lib',
 'D:\\Python',
 'D:\\Python\\Pythonwin',
 'D:\\Python\\Lib\\plat-win',
 'D:\\Python\\Lib',
 'D:\\Python\\DLLs',
 'D:\\Python\\Lib\\lib-tk',
 'ick',
 'fooey\\DLLs',
 'ick',
 'fooey\\lib',
 'ick',
 'fooey\\lib\\plat-win',
 'ick',
 'fooey\\lib\\lib-tk',
 'D:\\PYTHON']
>>>

Doesn't appear to be sensible, but at least it's predictable <wink>.

I was surprised to find that setting PYTHONPATH can't be used to override
any of this -- it just inserts even more stuff, into sys.path[1:1].

Do I really care?  Not much -- the complexity just makes it hard to get a
mental model of what Python *thinks* it's trying to accomplish here, and so
harder to figure out what needs to be done.  Which is pretty severe:
"Dragon std" apps must run the same version of Python (which can be local)
with the same libraries (which must be network-mounted), regardless of
whatever version of Python each user may have built on their own, and
regardless of their registry settings or envar values.

I think this means I need to distribute a python15.dll and python.exe (via
our source control system) into a directory very early on the PATH (other
common .exe's are distributed this way, so no big deal), and add a
sitecustomize.py that replaces all of sys.path with the Big Four
(Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the
common Dragon dir.

Network name mangling being what it is, I suppose I'll also need to force
PYTHONCASEOK.  There's no way to do that from within Python, is there?  If
not, everyone going through "unfortunate" paths in the network will have to
set that themselves.

Anyone have better ideas?  That shouldn't be hard <wink>.

the-difference-between-one-user-and-two-is-infinite-ly y'rs  - tim




From mhammond@skippinet.com.au  Fri Oct 15 09:02:14 1999
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Fri, 15 Oct 1999 18:02:14 +1000
Subject: [Python-Dev] Corporate installations
In-Reply-To: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <000101bf16e3$984577e0$0801a8c0@bobcat>

>  The 4 after that are a mystery, and duplicate the
> preceding 4 (except
> for meaningless-- it's Windows <wink> -- case differences).

Python makes a brave attempt to deduce the PYTHONHOME itself by
looking for "well-known" files in the lib directory.  Python15.dll
uses argv[0] or the result of GetModuleFileName(NULL) (whichever is
deemed "better" by the existance of a slash) as the basis for a search
for the landmark file.  If found, those 4 entries are added and if not
they are added relatively (ie ".\lib" in the vain hope they will
suddenly become meaningful (which they almost certainly wont)

So, when running a .EXE that lives in the main Python directory (such
as Python.exe), we get duplicated entries - the ones we deduced, and
the ones explicitely in the registry.

The problem arises when Python15.dll is used by a .exe that doesnt
live in this nice directory - eg Pythonwin, or any other embedding,
such as COM objects or peoples custom apps.  As argv[0] and
GetModuleFileName(NULL) both return a directory where "\lib" appended
will not find the landmark file (string.py for windows), you get the
useless relative paths added.

So, what this means is that Python's strategy for deducing the
PythonPath only works for Python.exe and Pythonw.exe - typically the
only .exes in the Python directory.  So we have the situation where
the paths must also be registered in the registry if any other .exe
wants to work.

> I was surprised to find that setting PYTHONPATH can't be used
> to override
> any of this -- it just inserts even more stuff, into sys.path[1:1].

Once upon a time Guido stated that PYTHONPATH should override the
registry completely.  I cant recall the history of this tho, and
wouldnt object is that was the case.  You are then faced with how to
set this env variable (and if you are doing that, why not just set the
registry?)

> I think this means I need to distribute a python15.dll and
> python.exe (via
> our source control system) into a directory very early on the
> PATH (other
> common .exe's are distributed this way, so no big deal), and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC
> paths, + the
> common Dragon dir.

This should be fine - as long as no one needs to run any other .EXE
that needs Python15.dll (or unless that other .exe is also in that
same directory).

> Network name mangling being what it is, I suppose I'll also
> need to force
> PYTHONCASEOK.  There's no way to do that from within Python,
> is there?  If

While my views on this have temepered from illogically ranting to
Guido how much I hate it, I still believe this is a mis-feature for
Windows.

The other alternative is to put Python.exe on the network path, and
have your library in a ".\lib" directory under that.  Doesnt really
solve the problem for your "DragonLib" stuff - Im sure you dont want
to stuff _everything_ into a single .lib directory.

Also, IMO Python shouldnt bother going sniffing for its library if the
registry exists.  It just adds time to startup, and if it works is
almost guaranteed to be redundant, and if it doesnt work will add
useless entries that slow down module searches.  However, that still
doesnt solve your problem.

The final suggestion is to put some of the win32 extensions
(specifically, win32api) on a network share along with Python.exe and
the standard lib.  Then provide a .bat file that actually sets up the
registry, and off you go.  Sure, people hate the registry, but setting
an environment variable is worse.  Or an alternative - provide a .reg
file with the necessary registry keys - users can "execute" it
(double-clicking from explorer, typing the name in start->run, execute
"start whatever.reg in their logon script, etc) to have their registry
setup.

I wish I had a better answer, but can't for the life of me work out
what it should be even if MS supported it!


Mark.



From mal@lemburg.com  Fri Oct 15 09:34:14 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 15 Oct 1999 10:34:14 +0200
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <3806E706.82FEB673@lemburg.com>

Tim Peters wrote:
> 
> Python is getting used widely enough in my place of employment that people
> are agitating for a common installation (personal variants are screwing
> people too often).  Various machines are running Win95, Win98, NT,
> Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS.  I'll choke
> on that whole banana when it's shoved down my throat.
> 
> For starters, I just need to get it running across Windows platforms.  Never
> looked into this before, and it seems to be exceedingly complicated right
> out of the box <0.5 wink>:
> 
> D:\Python>python
> Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import sys
> ['',
>  'D:\\Python\\win32',
>  'D:\\Python\\win32\\lib',
>  'D:\\Python',
>  'D:\\Python\\Pythonwin',
>  'D:\\Python\\Lib\\plat-win',
>  'D:\\Python\\Lib',
>  'D:\\Python\\DLLs',
>  'D:\\Python\\Lib\\lib-tk',
>  'D:\\PYTHON\\DLLs',
>  'D:\\PYTHON\\lib',
>  'D:\\PYTHON\\lib\\plat-win',
>  'D:\\PYTHON\\lib\\lib-tk',
>  'D:\\PYTHON']
> >>>
> 
> Where does all that stuff come from?  The first is apparently the current
> directory; cool.  The next 4 appear to come from MarkH's stuff, via the
> registry.  The next 4 appear to come from Python's own registry PythonPath
> key.  The 4 after that are a mystery, and duplicate the preceding 4 (except
> for meaningless-- it's Windows <wink> -- case differences).  The last is
> another mystery.  site.py isn't implicated in any of them (same thing when
> running with -S).

On Linux I get:

['',
 '/home/lemburg/bin',
 '/home/lemburg/lib',
 '/home/lemburg/projects',
 '/home/lemburg/python/Lib/',
 '/home/lemburg/python/Lib/test',
 '/home/lemburg/python/Lib/plat-linux2',
 '/home/lemburg/python/Lib/lib-tk',
 '/home/lemburg/python/Modules',
 '/usr/local/lib/python1.5/site-packages']

It seems that the last entry refers to what Python thinks is the standard
location for system wide extensions. The first 3 come from my PYTHONPATH
setting, the next few are inserted by the Python startup code based
on what Python found as landmark to determine PYTHONHOME.

> I think this means I need to distribute a python15.dll and python.exe (via
> our source control system) into a directory very early on the PATH (other
> common .exe's are distributed this way, so no big deal), and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the
> common Dragon dir.

Sounds reasonable ;-)

> Network name mangling being what it is, I suppose I'll also need to force
> PYTHONCASEOK.  There's no way to do that from within Python, is there?  If
> not, everyone going through "unfortunate" paths in the network will have to
> set that themselves.

If Windows allows writing the process' environment you can set PYTHONCASEOK
dynamically: the check queries the environment for the flag prior
to every check (instead of doing going the usual internal Python flag
way as many of the others do). See Python/import.c:check_case() for details.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    77 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From jim@interet.com  Fri Oct 15 16:22:38 1999
From: jim@interet.com (James C. Ahlstrom)
Date: Fri, 15 Oct 1999 11:22:38 -0400
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <380746BE.FAE46A0A@interet.com>

Tim Peters wrote:
> ['',
>  'D:\\Python\\win32',
>  'D:\\Python\\win32\\lib',
>  'D:\\Python',
>  'D:\\Python\\Pythonwin',
>  'D:\\Python\\Lib\\plat-win',
>  'D:\\Python\\Lib',
>  'D:\\Python\\DLLs',
>  'D:\\Python\\Lib\\lib-tk',
>  'D:\\PYTHON\\DLLs',
>  'D:\\PYTHON\\lib',
>  'D:\\PYTHON\\lib\\plat-win',
>  'D:\\PYTHON\\lib\\lib-tk',
>  'D:\\PYTHON']
> >>>
> 
> Where does all that stuff come from?

Good question.  I don't know, and every time I start to
think I do, I am wrong.  Certainly PYTHONPATH is full of
junk on Windows.

The point is that PYTHONPATH just doesn't work for commercial
installations.  Please see these for some discussion:

  ftp://ftp.interet.com/bootmodule.html
  ftp://ftp.interet.com/pylib.html

I think the solution is to put the library
files and packages into archive files (in some format yet
to be determined) and find them by looking in the
directory of python15.dll and/or python.exe.   On Unix
there is $prefix, which actually seems to work.

> I think this means I need to distribute a python15.dll and python.exe (via
> our source control system) into a directory very early on the PATH

Yes, that is a good start.  Just understand that *.pyd and and DLL's
which are imported
(instead of linked against) are found from PYTHONPATH, not PATH.  Also
you will need a valid PATH on all PC's which is quite a bother.  An
alternative is to use the Wise installer to set up icons for your
apps.  Real Windows apps don't use PATH.  We use Wise for internal
as well as external apps.

Note that if you import a module "import foo", and foo
lives in "foo.dll", then on Windows, PYTHONPATH is searched, and
the standard Windows DLL path is not searched.  That means you
can't use standard Windows locations for DLL's which are dynamically
imported.  This is an error and should be fixed.

> and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk)

The problem is that you already need a valid PYTHONPATH to
find sitecustomize.py.  Better is to create a custom python15.dll
with sitecustomize.py, exceptions.py and site.py (all needed during
boot)
frozen in as frozen modules.  In our office I freeze in other library
files too.

> Network name mangling being what it is, I suppose I'll also need to force
> PYTHONCASEOK.

I don't seem to need that on 95/98/NT.  Network names shouldn't
get mangled on these systems.  I guess you mean lack of case
sensitivity, but just make sure the case is correct in the Lib
directory.  This is another reason to prefer archive files anyway.
But no, you shouldn't need PYTHONCASEOK.

> Anyone have better ideas?  That shouldn't be hard <wink>.

Yes, this is a major problem with Python's acceptance for
commercial apps (and I include internal production code as
an app) so lets figure out what to do and fix it.

Jim Ahlstrom


From jim@interet.com  Fri Oct 15 19:19:41 1999
From: jim@interet.com (James C. Ahlstrom)
Date: Fri, 15 Oct 1999 14:19:41 -0400
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com>
Message-ID: <3807703D.9FD09C5B@interet.com>

"James C. Ahlstrom" wrote:
Sorry, correct URL is:

   ftp://ftp.interet.com/pub/bootmodule.html
   ftp://ftp.interet.com/pub/pylib.htm

Jim Ahlstrom


From fredrik@pythonware.com  Fri Oct 15 20:17:05 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 15 Oct 1999 21:17:05 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com>
Message-ID: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>

while doing the final checks for my upcoming
standard library guide, I thought I'd check what
had changed in the CVS version.

some old (1.5.1) junk was still to be found in the
lib-old subdirectory, but certain 1.5.2 things seem
to have vanished into thin air.

like find.py, for example.  does anyone know
where it is?  after all, it's kinda useful, and I
just pointed someone to it, only to find that
he didn't have it on his machine...

is there an official list of totally deprecated
modules somewhere?

</F>



From Fred L. Drake, Jr." <fdrake@acm.org  Fri Oct 15 20:44:29 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 15 Oct 1999 15:44:29 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
 <380746BE.FAE46A0A@interet.com>
 <3807703D.9FD09C5B@interet.com>
 <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
Message-ID: <14343.33821.523179.786228@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > some old (1.5.1) junk was still to be found in the
 > lib-old subdirectory, but certain 1.5.2 things seem
 > to have vanished into thin air.
 > 
 > like find.py, for example.  does anyone know
 > where it is?  after all, it's kinda useful, and I

  It should be in lib-old.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives


From fredrik@pythonware.com  Fri Oct 15 20:58:17 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 15 Oct 1999 21:58:17 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim><380746BE.FAE46A0A@interet.com><3807703D.9FD09C5B@interet.com><006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us>
Message-ID: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>

Fred L. Drake, Jr. <fdrake@acm.org> wrote:
>  > like find.py, for example.  does anyone know
>  > where it is?  after all, it's kinda useful, and I
> 
>   It should be in lib-old.

"should" as in "is already there" or
"oops, I'll fix it" ? :-)

</F>

[fredrik@brain BleedingEdge]$ ls python/dist/src/Lib/lib-old/
CVS           codehack.py   newdir.py     rand.py       whatsound.py
Para.py       fmt.py        ni.py         tb.py         zmod.py
addpack.py    lockfile.py   poly.py       util.py

(sure looks like "oops" to me...)



From Fred L. Drake, Jr." <fdrake@acm.org  Fri Oct 15 21:41:14 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 15 Oct 1999 16:41:14 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
 <380746BE.FAE46A0A@interet.com>
 <3807703D.9FD09C5B@interet.com>
 <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
 <14343.33821.523179.786228@weyr.cnri.reston.va.us>
 <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
Message-ID: <14343.37226.964388.867049@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > "should" as in "is already there" or
 > "oops, I'll fix it" ? :-)

  It's certainly in lib-old/ in the CVS repository.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives


From tismer@appliedbiometrics.com  Fri Oct 15 22:55:36 1999
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Fri, 15 Oct 1999 23:55:36 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>
 <380746BE.FAE46A0A@interet.com>
 <3807703D.9FD09C5B@interet.com>
 <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
 <14343.33821.523179.786228@weyr.cnri.reston.va.us>
 <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us>
Message-ID: <3807A2D8.7E7F91F8@appliedbiometrics.com>


"Fred L. Drake, Jr." wrote:
> 
> Fredrik Lundh writes:
>  > "should" as in "is already there" or
>  > "oops, I'll fix it" ? :-)
> 
>   It's certainly in lib-old/ in the CVS repository.

Sorry. Definately certainly not.

But a find.py is in Demo/threads. 
Fred (any of both :) did you mean that?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home


From fredrik@pythonware.com  Mon Oct 18 08:31:16 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Mon, 18 Oct 1999 09:31:16 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>	<380746BE.FAE46A0A@interet.com>	<3807703D.9FD09C5B@interet.com>	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>	<14343.33821.523179.786228@weyr.cnri.reston.va.us>	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com>
Message-ID: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>

> >  > "should" as in "is already there" or
> >  > "oops, I'll fix it" ? :-)
> > 
> >   It's certainly in lib-old/ in the CVS repository.
> 
> Sorry. Definately certainly not.
> 
> But a find.py is in Demo/threads. 
> Fred (any of both :) did you mean that?

I cannot see any "find.py" in either Lib (where it
is in all my copies of 1.5.2) or Lib/lib-old.

fwiw, I can think of a few dozen other standard
library modules that I'd remove before this one.
cannot we put it back?  please? :-)

(after all, it's been a reoccuring theme on
comp.lang.python lately.  and 1.5.2+ breaks
my new book...).

</F>



From Fred L. Drake, Jr." <fdrake@acm.org  Mon Oct 18 15:31:34 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 18 Oct 1999 10:31:34 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
 <380746BE.FAE46A0A@interet.com>
 <3807703D.9FD09C5B@interet.com>
 <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
 <14343.33821.523179.786228@weyr.cnri.reston.va.us>
 <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
 <14343.37226.964388.867049@weyr.cnri.reston.va.us>
 <3807A2D8.7E7F91F8@appliedbiometrics.com>
 <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
Message-ID: <14347.12102.276497.310651@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > I cannot see any "find.py" in either Lib (where it
 > is in all my copies of 1.5.2) or Lib/lib-old.

  It most certainly *should* be appearing in lib-old; I just checked
the internal CVS repository and it's really there.  Perhaps the
anonymous mirror isn't right?
  (Barry, can you check this?  I don't even know where it is, much
less whether I can see those directories.)

 > fwiw, I can think of a few dozen other standard
 > library modules that I'd remove before this one.
 > cannot we put it back?  please? :-)

  That's up to Guido, not me.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives


From guido@CNRI.Reston.VA.US  Mon Oct 18 15:56:55 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 18 Oct 1999 10:56:55 -0400
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: Your message of "Mon, 18 Oct 1999 09:31:16 +0200."
 <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com>
 <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
Message-ID: <199910181456.KAA22936@eric.cnri.reston.va.us>

> I cannot see any "find.py" in either Lib (where it
> is in all my copies of 1.5.2) or Lib/lib-old.

It *is* in Lib/lib-old.  Maybe the CVS mirror is messed up, we'll ask
Barry to investigate.  Maybe the branching messed things up?

> fwiw, I can think of a few dozen other standard
> library modules that I'd remove before this one.
> cannot we put it back?  please? :-)

It's better (and more illustrative) to use os.walk() to do this thing.

> (after all, it's been a reoccuring theme on
> comp.lang.python lately.  and 1.5.2+ breaks
> my new book...).

Good thing it isn't printed yet. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Mon Oct 18 16:35:04 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 18 Oct 1999 11:35:04 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>
 <380746BE.FAE46A0A@interet.com>
 <3807703D.9FD09C5B@interet.com>
 <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
 <14343.33821.523179.786228@weyr.cnri.reston.va.us>
 <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
 <14343.37226.964388.867049@weyr.cnri.reston.va.us>
 <3807A2D8.7E7F91F8@appliedbiometrics.com>
 <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
 <199910181456.KAA22936@eric.cnri.reston.va.us>
Message-ID: <14347.15912.178116.186186@anthem.cnri.reston.va.us>

>>>>> "Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:

    Guido> It *is* in Lib/lib-old.  Maybe the CVS mirror is messed up,
    Guido> we'll ask Barry to investigate.  Maybe the branching messed
    Guido> things up?

Somehow the mirror was out of date.  Perhaps the branch merge got it
out of whack, but in any case, I've done a top-level resync.  find.py
is definitely in the repository under lib-old now!

Hope that helps,
-Barry


From ggr@qualcomm.com  Tue Oct 19 16:30:01 1999
From: ggr@qualcomm.com (Barry A. Warsaw)
Date: Tue, 19 Oct 1999 11:30:01 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Greg Rose
Message-ID: <14348.36473.112615.887932@anthem.cnri.reston.va.us>

Folks, I'm resending this message here for Greg Rose.  If anybody can
help him out, please respond to ggr@qualcomm.com (not to me).

Greg, if you still get no response, then I suggest sending the mssage
to greater python-list@python.org.  There's gotta be /somebody/ out
there who is interested in participating.

-Barry

------- start of forwarded message (RFC 934 encapsulation) -------
From: Greg Rose <ggr@qualcomm.com>
To: bwarsaw@python.org
Subject: Re: python advocate in Perl/Python/Tcl bakeoff
Date: Tue, 19 Oct 1999 20:28:37 +1000
X-Sender: ggr2@avalon.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 

At 17:07 30/09/1999 -0400, you wrote:
>Hope that helps.  If neither of these guys can do it, and can't
>suggest someone who can, let me know and we'll post an announcement on 
>all the usual Python haunts.

Well, as they say, those who volunteer end up doing things...

I've tried both of your associates, and about three or four others who were
recommended, and have struck out. I'd really appreciate your help trying to
find someone competent to do this. Bear in mind that the audience is
sysadmins, not generic programmers.

thanks in advance,
Greg.

Here's the text I've been sending out, but you should feel free to modify
non-factual stuff:

Long ago there was a shell/perl/awk bakeoff invited talk at a USENIX
conference somewhere or other. It was fun for all involved, and was very
well received. We're looking to do something similar at the LISA conference
in Seattle. You have been recommended as Python advocate.

It would be on thursday 11th november. The idea would be to have a
moderator and three advocates, and a slightly rowdy audience. We'd ask each
advocate to nominate in advance some simple sysadmin task which shows their
language to its advantage, and also to do the solutions to the other two's
tasks... then there'd be some room for (presubmitted) tasks from the
audience to be solved on the fly. Any suggestions you have regarding how to
make it work would be appreciated.

Are you intending to attend LISA? Would you be willing to do this? (We have
Tom Christiansen for perl and Brent Welch for Tcl/Tk.)


Greg Rose                                     INTERNET: ggr@Qualcomm.com
Qualcomm Australia        VOICE:  +61-2-9181-4851   FAX: +61-2-9181-5470
Suite 410, Birkenhead Point,             http://people.qualcomm.com/ggr/ 
Drummoyne NSW 2047    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

------- end -------


From guido@CNRI.Reston.VA.US  Tue Oct 19 16:49:10 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Tue, 19 Oct 1999 11:49:10 -0400
Subject: [Python-Dev] forwarded message from Greg Rose
In-Reply-To: Your message of "Tue, 19 Oct 1999 11:30:01 EDT."
 <14348.36473.112615.887932@anthem.cnri.reston.va.us>
References: <14348.36473.112615.887932@anthem.cnri.reston.va.us>
Message-ID: <199910191549.LAA25773@eric.cnri.reston.va.us>

Alas, I'll be at SD99 East in DC that week, teaching Python CGI
programming.  See http://www.python.org/Events.html

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da@ski.org  Tue Oct 19 17:58:34 1999
From: da@ski.org (David Ascher)
Date: Tue, 19 Oct 1999 09:58:34 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Irrelevant but very informative piece of patent law
Message-ID: <Pine.WNT.4.04.9910190955170.286-100000@rigoletto.ski.org>

http://slashdot.org/features/99/10/19/1032254.shtml

Very well written, too.  Many many standard deviations away from standard
slashdot fare.

--da



From mhammond@skippinet.com.au  Sat Oct 30 00:11:54 1999
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sat, 30 Oct 1999 09:11:54 +1000
Subject: [Python-Dev] Embedding Python when using different calling conventions.
Message-ID: <004201bf2262$fe5cfeb0$0501a8c0@bobcat>

This is a bit yucky, but still a valid problem.

Malte Kroeger [kroeger@bigfoot.com] recently posted to python-help
with a problem.  He has an existing Windows project that he wishes to
use Python in.  This project does not use the standard __cdecl calling
convention that Python uses, for various reasons known only to him.
As it is an existing project and quite probably a large, complex one,
I am willing to accept that moving his existing project to match
Python's calling convention is not reasonable.  I also feel for him,
as I have personally battled this - both with Python and with other
projects.

He has requested that Python explicitely declare the calling
convention it uses.  Thus, it can be embedded in any project.

He wants a new macro.  Eg:

DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *));
becomes
DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *));

I suggested embedding the calling convention in with the DL_IMPORT
macro, but he pointed out this macro is also used for variables, where
the convention syntax is illegal.

To my mind this is reasonable (maybe not the spelling, but definately
the intent).  Any thoughts?

Mark.



From mal@lemburg.com  Sat Oct 30 09:46:30 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 30 Oct 1999 10:46:30 +0200
Subject: [Python-Dev] Embedding Python when using different calling
 conventions.
References: <004201bf2262$fe5cfeb0$0501a8c0@bobcat>
Message-ID: <381AB066.B54A47E0@lemburg.com>

Mark Hammond wrote:
> 
> This is a bit yucky, but still a valid problem.
> 
> Malte Kroeger [kroeger@bigfoot.com] recently posted to python-help
> with a problem.  He has an existing Windows project that he wishes to
> use Python in.  This project does not use the standard __cdecl calling
> convention that Python uses, for various reasons known only to him.
> As it is an existing project and quite probably a large, complex one,
> I am willing to accept that moving his existing project to match
> Python's calling convention is not reasonable.  I also feel for him,
> as I have personally battled this - both with Python and with other
> projects.

Isn't the default calling scheme selectable via compiler switches ?
I remember that this was the case with the IBM compiler on OS/2.
 
> He has requested that Python explicitely declare the calling
> convention it uses.  Thus, it can be embedded in any project.
> 
> He wants a new macro.  Eg:
> 
> DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *));
> becomes
> DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *));
> 
> I suggested embedding the calling convention in with the DL_IMPORT
> macro, but he pointed out this macro is also used for variables, where
> the convention syntax is illegal.

Perhaps switching to DL_IMPORT_FUNCTION(int) for functions would be a
better idea. This would leave the previous definition of DL_IMPORT
untouched (which is used by a few extensions too).

OTOH, we could take chance to reorganize these macros from bottom
up: when I started coding extensions I found them not very useful
mostly because I didn't have control over them meaning "export
this symbol" or "import the symbol". Especially the DL_IMPORT
macro is strange because it seems to handle both import *and*
export depending on whether Python is compiled or not.

FYI, I'm using these macros for the mx extensions:

/*
  Macros to control export and import of DLL symbols.

  We use our own definitions since Python's don't allow specifying
  both imported and exported symbols at the same time.

*/

/* Macro to "mark" a symbol for DLL export */

#if (defined(_MSC_VER) && _MSC_VER > 850		\
     || defined(__MINGW32__) || defined(__BEOS__))
# ifdef __cplusplus
#   define MX_EXPORT(type) extern "C" type __declspec(dllexport) 
# else
#   define MX_EXPORT(type) extern type __declspec(dllexport) 
# endif

#elif defined(__WATCOMC__)
#   define MX_EXPORT(type) extern type __export 

#else
#   define MX_EXPORT(type) extern type
#endif

/* Macro to "mark" a symbol for DLL import */

#if defined(__BORLANDC__)
#   define MX_IMPORT(type) extern type __import

#elif (defined(_MSC_VER) && _MSC_VER > 850		\
       || defined(__MINGW32__) || defined(__BEOS__))
# ifdef __cplusplus
#   define MX_IMPORT(type) extern "C" type __declspec(dllimport)
# else
#   define MX_IMPORT(type) extern type __declspec(dllimport)
# endif

#else
#   define MX_IMPORT(type) extern type
#endif

plus these kind of defines in the extension header files:

#ifdef MX_BUILDING_MXDATETIME
# define MXDATETIME_EXTERNALIZE MX_EXPORT
#else
# define MXDATETIME_EXTERNALIZE MX_IMPORT
#endif

Note that MX_EXPORT always defines export symbols and MX_IMPORT
always means "import the symbol". The *_EXTERNALIZE macro decides
which form to take depending on whether the header file is used
to compile the extension itself or using the extension.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    62 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gmcm@hypernet.com  Sun Oct 31 15:59:16 1999
From: gmcm@hypernet.com (Gordon McMillan)
Date: Sun, 31 Oct 1999 10:59:16 -0500
Subject: [Python-Dev] dircache.py
Message-ID: <1270737688-19939033@hypernet.com>

Pursuant to my volunteering to implement Guido's plan to 
combine cmp.py, cmpcache.py, dircmp.py and dircache.py 
into filecmp.py, I did some investigating of dircache.py.

I find it completely unreliable. On my NT box, the mtime of the 
directory is updated (on average) 2 secs after a file is added, 
but within 10 tries, there's always one in which it takes more 
than 100 secs (and my test script quits). My Linux box hardly 
ever detects a change within 100 secs.

I've tried a number of ways of testing this ("this" being 
checking for a change in the mtime of the directory), the latest 
of which is below. Even if dircache can be made to work 
reliably and surprise-free on some platforms, I doubt it can be 
done cross-platform. So I'd recommend that it just get dropped.

Comments?

---------------------------------------------------
import os
import sys
import time
d = os.getcwd()
atimes = []

def test():
    m = os.stat(d)[8]
    for i in range(10):
        fnm = 's%d.tmp' % i
        open(fnm,'w').write('dummy - delete me')
        for j in range(10000):
            newm = os.stat(d)[8]
            if newm != m:
                atimes.append(j*0.01)
                m = newm
                break
            time.sleep(0.01)
        else:
            print "At round %d, failed to detect add within %3.2f 
secs" % (i, j*0.01)
            break

def report():
    import operator
    if atimes:
        print "detect adds:   min= %3.2f max= %3.2f avg= 
%3.2f" % (min(atimes), max(atimes), reduce(operator.add, 
atimes, 0.0)/len(atimes))
    else:
        print "no successfully detected adds"

test()
report()

- Gordon


From mal@lemburg.com  Sun Oct 31 23:00:55 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 01 Nov 1999 00:00:55 +0100
Subject: [Python-Dev] Misleading syntax error text
References: <1270838575-13870925@hypernet.com>
Message-ID: <381CCA27.59506CF6@lemburg.com>

[Extracted from the psa-members list...]

Gordon McMillan wrote:
> 
> Chris Fama wrote,
> > And now the rub: the exact same function definition has passed
> > through byte-compilation perfectly OK many times before with no
> > problems... of course, this points rather clearly to the
> > preceding code, but it illustrates a failing in Python's syntax
> > error messages, and IMHO a fairly serious one at that, if this is
> > indeed so.
> 
> My simple experiments refuse to compile a "del getattr(..)" at
> all.

Hmm, it seems to be a failry generic error:

>>> del f(x,y)
SyntaxError: can't assign to function call

How about chainging the com_assign_trailer function in Python/compile.c
to:

static void
com_assign_trailer(c, n, assigning)
        struct compiling *c;
        node *n;
        int assigning;
{
        REQ(n, trailer);
        switch (TYPE(CHILD(n, 0))) {
        case LPAR: /* '(' [exprlist] ')' */
                com_error(c, PyExc_SyntaxError,
                          assigning ? "can't assign to function call":
			              "can't delete expression");
                break;
        case DOT: /* '.' NAME */
                com_assign_attr(c, CHILD(n, 1), assigning);
                break;
        case LSQB: /* '[' subscriptlist ']' */
                com_subscriptlist(c, CHILD(n, 1), assigning);
                break;
        default:
                com_error(c, PyExc_SystemError, "unknown trailer type");
        }
}

or something along those lines...

BTW, has anybody tried my import patch recently ? I haven't heard
any citicism since posting it and wonder what made the list fall
asleep over the topic :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    61 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mhammond at skippinet.com.au  Fri Oct  1 02:27:03 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 1 Oct 1999 10:27:03 +1000
Subject: [Python-Dev] getopt helper?
In-Reply-To: <14323.51267.54862.538939@anthem.cnri.reston.va.us>
Message-ID: <001601bf0ba3$b06ad770$0801a8c0@bobcat>

OK - general agreement.  Wheee :-)

How about this:

def getopt_or_die(opts,
                  long_opts=[],
                  usage=None,
                  prog_name=None,
                  args=None,
                  exit_code = 1):

if usage is None, we build a very simple usage string from
opts/long_opts.

If prog_name is None, we use os.path.basename(sys.argv[0]).  This is
printed just before the usage message.

If args is None, we use sys.argv[1:]

exit_code specifies the param to sys.exit() on invalid options.

I have based the ordering on my guess at the most likely to be used -
but maybe "prog_name" and "args" should be reversed?  This should
_not_ be all-singing, all-dancing, as it is simple to use the existing
getopt.getopt() directly for more esoteric requirements; the old 80-20
rule applies here :-)

If the general agreement continues, I will then knock together an
implementation.

Mark.




From gward at cnri.reston.va.us  Fri Oct  1 02:51:37 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Thu, 30 Sep 1999 20:51:37 -0400
Subject: [Python-Dev] getopt helper?
In-Reply-To: <001601bf0ba3$b06ad770$0801a8c0@bobcat>; from Mark Hammond on Fri, Oct 01, 1999 at 10:27:03AM +1000
References: <14323.51267.54862.538939@anthem.cnri.reston.va.us> <001601bf0ba3$b06ad770$0801a8c0@bobcat>
Message-ID: <19990930205136.A14297@cnri.reston.va.us>

On 01 October 1999, Mark Hammond said:
> OK - general agreement.  Wheee :-)
> 
> How about this:
> 
> def getopt_or_die(opts,
>                   long_opts=[],
>                   usage=None,
>                   prog_name=None,
>                   args=None,
>                   exit_code = 1):
> 
> if usage is None, we build a very simple usage string from
> opts/long_opts.

I still think it would be very desirable to tie the short and long
options together.  Eg.

  options = [('verbose', 'v'),
             ('quiet', 'q'),
             ('thingy', None),
             (None, 'x')
             ('output=', 'o:')]
  opts, args = getopt_or_die (options, usage, ...)

Then opts would have possible keys 'verbose', 'quiet', 'thingy', 'x',
and 'value' -- never 'v', 'q', or 'o'

(Look, I restrained my tendency to invent type systems and auto-generate
help text.  There may be hope for me yet.)

        Greg



From tim_one at email.msn.com  Fri Oct  1 07:55:46 1999
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 1 Oct 1999 01:55:46 -0400
Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports)
In-Reply-To: <199909181417.PAA20866@pukapuka.inrialpes.fr>
Message-ID: <000101bf0bd1$9b1cf5a0$842d153f@tim>

[Vladimir Marangozov, plugging]
> Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating
> Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978.

Wasn't Saltzer one of the CNRI fellows' advisors?  Jeremy's, perhaps?

it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs  - tim





From mhammond at skippinet.com.au  Sun Oct  3 09:52:59 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 3 Oct 1999 17:52:59 +1000
Subject: [Python-Dev] getopt helper?
In-Reply-To: <19990930205136.A14297@cnri.reston.va.us>
Message-ID: <001a01bf0d74$5031ed80$0801a8c0@bobcat>

Greg writes:
> I still think it would be very desirable to tie the short and long
> options together.  Eg.
>
>   options = [('verbose', 'v'),
>              ('quiet', 'q'),
>              ('thingy', None),
>              (None, 'x')
>              ('output=', 'o:')]
>   opts, args = getopt_or_die (options, usage, ...)
>

Im not convinced this is worth it.  I only use "long options" when I
have too many, or a few obscure ones.  I have never have "-v"
synonymous for "--verbose" - why bother?  I know I would never type
the later:-)

The existing mechanism still handles this quite well - the standard
"if opt==blah:" simply becomes "if opt in [...]:" - no real drag.

Plus its less change for reasonable reward - handy enough I may
actually add command-line handling as I create each little test/util
script :-)

What say anyone else?  Go with my "little change", Gregs "only
slightly more change" or "don't worry about it"?

Mark.




From skip at mojam.com  Sun Oct  3 16:26:54 1999
From: skip at mojam.com (Skip Montanaro)
Date: Sun, 3 Oct 1999 09:26:54 -0500 (CDT)
Subject: [Python-Dev] getopt helper?
In-Reply-To: <001a01bf0d74$5031ed80$0801a8c0@bobcat>
References: <19990930205136.A14297@cnri.reston.va.us>
	<001a01bf0d74$5031ed80$0801a8c0@bobcat>
Message-ID: <14327.26542.101415.144270@dolphin.mojam.com>

    Mark> Im not convinced this [pairing up long and short options] is worth
    Mark> it.

The primary reason where it would be helpful is to generate clearer default
usage strings.  Aside from that, I'm not sure the extra structure would be
worth it.

Skip



From jeremy at cnri.reston.va.us  Sun Oct  3 19:05:18 1999
From: jeremy at cnri.reston.va.us (Jeremy Hylton)
Date: Sun, 3 Oct 1999 13:05:18 -0400 (EDT)
Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports)
In-Reply-To: <000101bf0bd1$9b1cf5a0$842d153f@tim>
References: <199909181417.PAA20866@pukapuka.inrialpes.fr>
	<000101bf0bd1$9b1cf5a0$842d153f@tim>
Message-ID: <14327.36046.4763.670777@bitdiddle.cnri.reston.va.us>

>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:

  TP> [Vladimir Marangozov, plugging]
  >> Saltzer J., "Naming and Binding of Objects", in Bayer R.,
  >> "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60,
  >> 1978.

  TP> Wasn't Saltzer one of the CNRI fellows' advisors?  Jeremy's,
  TP> perhaps?

Indeed he was.

  TP> it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim

I think sixth degrees of separation only made sense in the pre-email
world.  These days it's probably down to four or five.

Jeremy





From mhammond at skippinet.com.au  Mon Oct  4 01:30:25 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 4 Oct 1999 09:30:25 +1000
Subject: [Python-Dev] ESR on slashdot
Message-ID: <002001bf0df7$45e964b0$0801a8c0@bobcat>

Just as a matter of interest, here is a question put to ESR and his
answer.  We certainly could do alot worse than to have ESR becoming a
real Python advocate :-)  If only Guido himself could find time to
work on 1.6, we would be "in like Flynn" :-)

Mark.

shawnhargreaves asks:
You've always been involved in hacker projects outside of just coding
(eg. the Jargon File), but over the last year or so the spokesperson
role seems to have grown into a fulltime job. How long is it since you
last sat down to write a major piece of software? Do you expect to go
back to fulltime development work anytime soon, and if so, what would
you work on? How do you manage to cope with the withdrawal symptoms?

ESR answers:
An astute question ;-). I haven't sat down to write a major piece of
software from scratch in months, but I am continuing to maintain
fetchmail. I just took over the gif2png beta code with Greg Roelofs's
consent; the 1.0.0 version might be out by the time you read this.
Today I did some work on gnuplot, bringing the PNG driver up to date.

If I get to go full-time again soon, I want to go back to work on
Trove, the distributed web-based code-archiving system I designed last
year. I'd also like to work with Guido van Rossum on Python 1.6; there
are some long-time wishlist features like rich comparisons and a full
lambda facility that I care enough about to implement myself. I also
have a strategy-gaming system I wrote back in the 1980s that I'd like
to put a modern (Web-based) interface on. Finally, having contributed
a bit of code to GNOME (the network-monitor applet) I'd like to
balance things by doing something for KDE.




From gstein at lyra.org  Mon Oct  4 11:51:53 1999
From: gstein at lyra.org (Greg Stein)
Date: Mon, 4 Oct 1999 02:51:53 -0700 (PDT)
Subject: [Python-Dev] Alternative Approach to Relative Imports
In-Reply-To: <37F21B2F.DD65738F@interet.com>
Message-ID: <Pine.LNX.4.10.9910040248120.27657-100000@nebula.lyra.org>

On Wed, 29 Sep 1999, James C. Ahlstrom wrote:
> "M.-A. Lemburg" wrote:
> > I know, but there still is no way to query what kind of hooks
> > are already loaded and what is worse, you cannot unload or reorder
> > them.
> 
> I think this is a valid point.  I am interested in hooks to read
> modules from a file archive.  If you are a developer, it is
> necessary to turn this hook OFF, so that you can revert to the
> usual directory tree where your current source is.
> 
> I am solving this by leaving a global variable "Importer" in
> sitecustomize, and calling sitecustomize.Importer.enable(0).
> This works, but it might be useful if imputil could de-install
> a hook as well as install it.

It was a design point to not provide this functionality. It is pretty
difficult to unhook the importers from the chain. I specifically said,
"well... when you alter the import behavior, then it will stay that way."

I figured this was entirely safe since an Importer could have an
enable/disable flag like you implemented, or my (theoretical) Import
Manager could pull an Importer out of its list that it was managing.

I'm not sure that we want an Import Manager to always be installed in the
hooks, but it could be a good idea to have a standard manager in the
library somewhere (which Importers could state a dependency upon its
installation).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/





From jim at interet.com  Mon Oct  4 17:16:28 1999
From: jim at interet.com (James C. Ahlstrom)
Date: Mon, 04 Oct 1999 11:16:28 -0400
Subject: [Python-Dev] Alternative Approach to Relative Imports
References: <Pine.LNX.4.10.9910040248120.27657-100000@nebula.lyra.org>
Message-ID: <37F8C4CC.6C230B06@interet.com>

Greg Stein wrote:

> It was a design point to not provide this functionality. It is pretty
> difficult to unhook the importers from the chain. I specifically said,
> "well... when you alter the import behavior, then it will stay that way."
> 
> I figured this was entirely safe since an Importer could have an
> enable/disable flag like you implemented, or my (theoretical) Import
> Manager could pull an Importer out of its list that it was managing.

I think my design of leaving a global "Importer" instance variable
in imputil is a bit lame.  Each importer is a class instance, but I
don't see a list of importers in imputil.

Suppose impuil kept a list of installed importers
imputil.ImporterList[].
Then to access an importer I have installed, I can write:
    for im in imputil.ImporterList:
      if isinstance(im, MyImporter):
        im.enable(0)
It would not be necessary to dis-install an importer, imputil would
just undertake to keep a list of installed importers, and if someone
wanted to control their installed importers, they would use the list.

I do not feel too strongly about this.  Maybe it is a good idea.
What do you think?  I can just use my global variable I guess.

Jim Ahlstrom



From fredrik at pythonware.com  Wed Oct  6 11:52:55 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 6 Oct 1999 11:52:55 +0200
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
Message-ID: <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com>

http://www.cobolscript.com/

    "[COBOL's] just a language whose superiority for
    developing certain types of modern systems has
    been overlooked until now"

    PROCEDURE DIVISION.
           0000-MAIN.
           DISPLAY WEB-PAGE-HEADER.
           ACCEPT DATA FROM WEBPAGE.
           COMPUTE grand_total = subtotal *(1  sales_tax_rate).
           DISPLAY WEB-PAGE-BODY.
           DISPLAY WEB-PAGE-FOOTER.

well, why not? :-)

</F>




From jack at oratrix.nl  Wed Oct  6 13:02:39 1999
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 06 Oct 1999 13:02:39 +0200
Subject: [Python-Dev] an alternative language for CP4E, perhaps? 
In-Reply-To: Message by "Fredrik Lundh" <fredrik@pythonware.com> ,
	     Wed, 6 Oct 1999 11:52:55 +0200 , <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com> 
Message-ID: <19991006110240.068AC35BB1E@snelboot.oratrix.nl>

> http://www.cobolscript.com/
> 
>     "[COBOL's] just a language whose superiority for
>     developing certain types of modern systems has
>     been overlooked until now"

The whole site sort-of makes me wonder whether this is one big elaborate joke. 
But if it is somebody put an incredible amount of work in it.

The funny thing is that the idea of using Cobol for web-programming _did_ 
initially strike me as a neat idea: because of the elaborate data descriptions 
and report generation facilities you could conceivably use all that info to 
automatically generate all the input forms and such. But they have apparently 
done no such thing...

The timesheet example is, uhm, interesting. 1500 lines of code, with many 
parameters hardcoded in the source. I'd be surprised if it would take more 
than 100 lines in Python, with a lot more customizability too.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From guido at CNRI.Reston.VA.US  Wed Oct  6 16:57:21 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 06 Oct 1999 10:57:21 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: Your message of "Wed, 06 Oct 1999 13:02:39 +0200."
             <19991006110240.068AC35BB1E@snelboot.oratrix.nl> 
References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> 
Message-ID: <199910061457.KAA08749@eric.cnri.reston.va.us>

> X-Last-Band-Seen: Raggende Mannen afscheidsconcert (Paradiso, 4-10)
> X-Mini-Review: IK HEB HET OVERLEEFD! IK HEB HET OVERLEEFD! IK HEB HET 
>     OVERLEEFD!

Ach!  Wish I was there!

> > http://www.cobolscript.com/
> > 
> >     "[COBOL's] just a language whose superiority for
> >     developing certain types of modern systems has
> >     been overlooked until now"

> The whole site sort-of makes me wonder whether this is one big
> elaborate joke.  But if it is somebody put an incredible amount of
> work in it.

Definitely a joke.  Try

http://www.cobolscript.com/csfaq.htm#question9

"One of the other advantages of COBOL is that COBOL file processing
statements are very simple, with no knowledge of disk head positioning
required."

But yes, an incredibly good one!  Worth filling out the form on the
"contact us page" and seeing what they send back.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gmcm at hypernet.com  Wed Oct  6 18:55:18 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 6 Oct 1999 12:55:18 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: <199910061457.KAA08749@eric.cnri.reston.va.us>
References: Your message of "Wed, 06 Oct 1999 13:02:39 +0200."             <19991006110240.068AC35BB1E@snelboot.oratrix.nl> 
Message-ID: <1272894334-31005071@hypernet.com>

[Guido, on http://www.cobolscript.com/]

> Definitely a joke.  Try
> 
> http://www.cobolscript.com/csfaq.htm#question9
> 
> "One of the other advantages of COBOL is that COBOL file
> processing statements are very simple, with no knowledge of disk
> head positioning required."
> 
> But yes, an incredibly good one!  Worth filling out the form on
> the "contact us page" and seeing what they send back.

While funny, I can virtually guaruntee these people are serious.

It is a common misperception among mainframe/COBOL 
types that C/Unix has *only* character I/O (which does not 
exist in the former environment at all - even terminals are 
block I/O). They regard this as a sign of their vast superiority. 
(And I dearly wish that born-again "Windoze" bashers be 
sentenced to work in this environment - they'll soon realize 
how closely related Windows and Unix are).

I did a number of stints introducing client / server to Big Blue 
shops. (Unix made it's entry *only* because RDBMS's ran on 
them, and all these shops claimed they would dump Unix as 
soon as these products worked right on big iron). I *always* 
had an endless fight with the people who wanted to use 
COBOL instead of C / C++ (on both the Unix boxes and the 
PCs). 

MicroFocus distributed a "white paper" comparing COBOL to 
C that I came to know very, very well. It came in 4 sections:
- the Executive Summary said COBOL was vastly superior in 
all respects
- the White Paper said COBOL was more maintainable 
(translation - you can hire brown-nosing dorks in suits, instead 
of geeks in T-shirts) and often had superior performance
- the Benchmark showed that C smoked COBOL in absolutely 
everything except binary search (a COBOL builtin)
- the Appendix showed that the C code for "binary search" 
was a very badly coded linear search.

But no shop had ever read past the Executive Summary.

And don't forget that there is probably more than one order-of-
magnitude more COBOL source out there than source in any 
other (or maybe all other) language(s). All with no built-in date 
type; and hardly ever using common date routines either 
(calling external programs in COBOL is expensive, and 
awkward, because all variables are global).

Y2K-compliant-by-omission-ly y'rs

- Gordon



From guido at CNRI.Reston.VA.US  Wed Oct  6 19:00:50 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 06 Oct 1999 13:00:50 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: Your message of "Wed, 06 Oct 1999 10:57:21 EDT."
             <199910061457.KAA08749@eric.cnri.reston.va.us> 
References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl>  
            <199910061457.KAA08749@eric.cnri.reston.va.us> 
Message-ID: <199910061700.NAA09211@eric.cnri.reston.va.us>

Now I'm confused...  I typed in the comment box:

	Very good joke.  ROFL.
	Where do you guys find the
	time and energy to do this!
	:-)

and got this back:

	Mr. van Rossum

	Glad you took the time out of your busy schedule to berate us.
	We must be doing something right! ;)

	Chuck Shereda
	Deskware, Inc.
	www.deskware.com
	www.cobolscript.com

--Guido van Rossum (home page: http://www.python.org/~guido/)



From klm at digicool.com  Wed Oct  6 19:19:30 1999
From: klm at digicool.com (klm)
Date: Wed, 6 Oct 1999 13:19:30 -0400 (EDT)
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: <199910061700.NAA09211@eric.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.9910061316460.3705-100000@korak.digicool.com>

On Wed, 6 Oct 1999, Guido van Rossum wrote:

> Now I'm confused...  I typed in the comment box:
> 
> [...]
> and got this back:
> 
>       Mr. van Rossum
> 
>       Glad you took the time out of your busy schedule to berate us.
>       We must be doing something right! ;)
> 
>       Chuck Shereda
>       Deskware, Inc.
>       www.deskware.com
>       www.cobolscript.com
 
Apparently deskware is a known, bona fide organization.  Considering the
massive number of cobol programmers around, and despite how cumbersome the
prospect is (and with the advantage of factoring in the things gordon
said), i guess someone thinks there's leverage in making cobol a scripting
language.  I think it's not so different than making interpreted versions
of C (but i'm not very C friendly).

Ken
klm at digicool.com




From klm at digicool.com  Wed Oct  6 20:05:21 1999
From: klm at digicool.com (Ken Manheimer)
Date: Wed, 6 Oct 1999 14:05:21 -0400 
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
Message-ID: <613145F79272D211914B0020AFF640191D1D2D@gandalf.digicool.com>

Concerning the possibility of cobolscript, i wrote:
 
> said), i guess someone thinks there's leverage in making cobol a
scripting
> language.  I think it's not so different than making interpreted
versions
> of C (but i'm not very C friendly).

After posting i thought this might come off as more ignorantly bigoted
than i meant for it to seem:-)  I was trying to say that C doesn't seem
very well suited to scripting/running interpreted, like cobol - not that
C is as fraught with ancient and awkward design as cobol (seems).

Sigh.

Ken
klm at digicool.com



From mal at lemburg.com  Mon Oct 11 22:36:07 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 11 Oct 1999 22:36:07 +0200
Subject: [Python-Dev] Walking up the package hierarchy
Message-ID: <38024A37.D92E7091@lemburg.com>

Hi everybody,

while I'm still thinking about writing the import manager, here
is a patch that implements the walk-up-the-hierarchy import scheme
that got so much positive feedback. I'm intending to use this
implementation as proof of concept for the switch to my new
package structure, but wouldn't mind seeing something like it
the distribution as well ;-)

It changes the default import mechanism to work like this:

>>> import d
try a.b.c.d
try a.b.d
try a.d
try d
fail

instead of just doing the current two-level lookup:

>>> import d
try a.b.c.d
try d
fail

As a result, relative imports referring to higher level packages
work out of the box without any ugly underscores in the import name.
Plus the whole scheme is pretty simple to explain and straightforward.

Since the patch is so small, I attached it to this mail. Hope
you don't mind. The ZIP archive also contains a sample package
which demonstrates the feature. Run Python with -v flag to see how
the new scheme works.

Feedback is most welcome. I am especially interested whether the
scheme breaks any existing packages.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    81 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: walkingimport.zip
Type: application/x-zip-compressed
Size: 2669 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/19991011/6ddcfec5/attachment.bin>

From bwarsaw at cnri.reston.va.us  Tue Oct 12 22:21:02 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Tue, 12 Oct 1999 16:21:02 -0400 (EDT)
Subject: [Python-Dev] string methods branch
Message-ID: <14339.38958.882650.342925@anthem.cnri.reston.va.us>

Guido has agreed to let me mainline the string methods branch.  Those
of you on python-checkins should have seen the CVS messages by now.
This is a good thing because I think we can all agree we hate CVS
branches.  For me, that final merge put the nail in the coffin.

Anyway, those of you who have put off playing with string methods
until now should just be able to do a CVS update, rebuild, and go.
You should read the revision log messages for the branch checkins for
details of the changes.  Let me know if you have any problems.  Fred
and I will work out changes to the documentation some time soon.

>>> sig=['branches','are','only','useful','for','trees','and','streams','ly']
>>> print '-'.join(sig) + " y'rs"

-Barry



From skip at mojam.com  Tue Oct 12 23:03:13 1999
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 12 Oct 1999 16:03:13 -0500
Subject: [Python-Dev] new opportunities for obfuscation... ;-)
Message-ID: <199910122103.QAA31864@dolphin.mojam.com>

Barry's note prompted me to update my Python tree.  The result:

    >>> ".".join(dir(""))
    'capitalize.count.endswith.find.index.join.lower.lstrip.replace.rfind.rindex.rstrip.split.startswith.strip.swapcase.translate.upper'

A job well done, Barry...

Skip Montanaro | http://www.mojam.com/
skip at mojam.com | http://www.musi-cal.com/
847-971-7098   | Python: Programming the way Guido indented...



From mal at lemburg.com  Wed Oct 13 14:27:57 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 13 Oct 1999 14:27:57 +0200
Subject: [Python-Dev] Walking up the package hierarchy
References: <38024A37.D92E7091@lemburg.com>
Message-ID: <38047ACD.E716154E@lemburg.com>

Strange... I would have thought that this new patch would stir up
some cheers or opposition. Has anyone tried it in some real apps ?

It would be interesting to see whether it breaks any code in e.g.
packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't
break anything for my packages or apps.

> It changes the default import mechanism to work like this:
> 
> >>> import d
> try a.b.c.d
> try a.b.d
> try a.d
> try d
> fail
> 
> instead of just doing the current two-level lookup:
> 
> >>> import d
> try a.b.c.d
> try d
> fail

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    79 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From Vladimir.Marangozov at inrialpes.fr  Thu Oct 14 13:26:11 1999
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Thu, 14 Oct 1999 12:26:11 +0100 (NFT)
Subject: [Python-Dev] Walking up the package hierarchy
In-Reply-To: <38047ACD.E716154E@lemburg.com> from "M.-A. Lemburg" at "Oct 13, 99 02:27:57 pm"
Message-ID: <199910141126.MAA32650@pukapuka.inrialpes.fr>

M.-A. Lemburg wrote:
> 
> Strange... I would have thought that this new patch would stir up
> some cheers or opposition. Has anyone tried it in some real apps ?

Not yet, but this looks better as a default search path.

> 
> It would be interesting to see whether it breaks any code in e.g.
> packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't
> break anything for my packages or apps.

JimF, /F, Guido and other package maintainers could do you a favor
by trying your patch ;-) and give us some real feedback on this.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From tim_one at email.msn.com  Fri Oct 15 09:21:15 1999
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 15 Oct 1999 03:21:15 -0400
Subject: [Python-Dev] Corporate installations
Message-ID: <000401bf16dd$def75d80$d72d153f@tim>

Python is getting used widely enough in my place of employment that people
are agitating for a common installation (personal variants are screwing
people too often).  Various machines are running Win95, Win98, NT,
Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS.  I'll choke
on that whole banana when it's shoved down my throat.

For starters, I just need to get it running across Windows platforms.  Never
looked into this before, and it seems to be exceedingly complicated right
out of the box <0.5 wink>:

D:\Python>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
['',
 'D:\\Python\\win32',
 'D:\\Python\\win32\\lib',
 'D:\\Python',
 'D:\\Python\\Pythonwin',
 'D:\\Python\\Lib\\plat-win',
 'D:\\Python\\Lib',
 'D:\\Python\\DLLs',
 'D:\\Python\\Lib\\lib-tk',
 'D:\\PYTHON\\DLLs',
 'D:\\PYTHON\\lib',
 'D:\\PYTHON\\lib\\plat-win',
 'D:\\PYTHON\\lib\\lib-tk',
 'D:\\PYTHON']
>>>

Where does all that stuff come from?  The first is apparently the current
directory; cool.  The next 4 appear to come from MarkH's stuff, via the
registry.  The next 4 appear to come from Python's own registry PythonPath
key.  The 4 after that are a mystery, and duplicate the preceding 4 (except
for meaningless-- it's Windows <wink> -- case differences).  The last is
another mystery.  site.py isn't implicated in any of them (same thing when
running with -S).  I suppose this is a clue:

D:\Python>set PYTHONHOME=ick;fooey

D:\Python>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
>>> sys.path
['',
 'D:\\Python\\win32',
 'D:\\Python\\win32\\lib',
 'D:\\Python',
 'D:\\Python\\Pythonwin',
 'D:\\Python\\Lib\\plat-win',
 'D:\\Python\\Lib',
 'D:\\Python\\DLLs',
 'D:\\Python\\Lib\\lib-tk',
 'ick',
 'fooey\\DLLs',
 'ick',
 'fooey\\lib',
 'ick',
 'fooey\\lib\\plat-win',
 'ick',
 'fooey\\lib\\lib-tk',
 'D:\\PYTHON']
>>>

Doesn't appear to be sensible, but at least it's predictable <wink>.

I was surprised to find that setting PYTHONPATH can't be used to override
any of this -- it just inserts even more stuff, into sys.path[1:1].

Do I really care?  Not much -- the complexity just makes it hard to get a
mental model of what Python *thinks* it's trying to accomplish here, and so
harder to figure out what needs to be done.  Which is pretty severe:
"Dragon std" apps must run the same version of Python (which can be local)
with the same libraries (which must be network-mounted), regardless of
whatever version of Python each user may have built on their own, and
regardless of their registry settings or envar values.

I think this means I need to distribute a python15.dll and python.exe (via
our source control system) into a directory very early on the PATH (other
common .exe's are distributed this way, so no big deal), and add a
sitecustomize.py that replaces all of sys.path with the Big Four
(Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the
common Dragon dir.

Network name mangling being what it is, I suppose I'll also need to force
PYTHONCASEOK.  There's no way to do that from within Python, is there?  If
not, everyone going through "unfortunate" paths in the network will have to
set that themselves.

Anyone have better ideas?  That shouldn't be hard <wink>.

the-difference-between-one-user-and-two-is-infinite-ly y'rs  - tim





From mhammond at skippinet.com.au  Fri Oct 15 10:02:14 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 15 Oct 1999 18:02:14 +1000
Subject: [Python-Dev] Corporate installations
In-Reply-To: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <000101bf16e3$984577e0$0801a8c0@bobcat>

>  The 4 after that are a mystery, and duplicate the
> preceding 4 (except
> for meaningless-- it's Windows <wink> -- case differences).

Python makes a brave attempt to deduce the PYTHONHOME itself by
looking for "well-known" files in the lib directory.  Python15.dll
uses argv[0] or the result of GetModuleFileName(NULL) (whichever is
deemed "better" by the existance of a slash) as the basis for a search
for the landmark file.  If found, those 4 entries are added and if not
they are added relatively (ie ".\lib" in the vain hope they will
suddenly become meaningful (which they almost certainly wont)

So, when running a .EXE that lives in the main Python directory (such
as Python.exe), we get duplicated entries - the ones we deduced, and
the ones explicitely in the registry.

The problem arises when Python15.dll is used by a .exe that doesnt
live in this nice directory - eg Pythonwin, or any other embedding,
such as COM objects or peoples custom apps.  As argv[0] and
GetModuleFileName(NULL) both return a directory where "\lib" appended
will not find the landmark file (string.py for windows), you get the
useless relative paths added.

So, what this means is that Python's strategy for deducing the
PythonPath only works for Python.exe and Pythonw.exe - typically the
only .exes in the Python directory.  So we have the situation where
the paths must also be registered in the registry if any other .exe
wants to work.

> I was surprised to find that setting PYTHONPATH can't be used
> to override
> any of this -- it just inserts even more stuff, into sys.path[1:1].

Once upon a time Guido stated that PYTHONPATH should override the
registry completely.  I cant recall the history of this tho, and
wouldnt object is that was the case.  You are then faced with how to
set this env variable (and if you are doing that, why not just set the
registry?)

> I think this means I need to distribute a python15.dll and
> python.exe (via
> our source control system) into a directory very early on the
> PATH (other
> common .exe's are distributed this way, so no big deal), and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC
> paths, + the
> common Dragon dir.

This should be fine - as long as no one needs to run any other .EXE
that needs Python15.dll (or unless that other .exe is also in that
same directory).

> Network name mangling being what it is, I suppose I'll also
> need to force
> PYTHONCASEOK.  There's no way to do that from within Python,
> is there?  If

While my views on this have temepered from illogically ranting to
Guido how much I hate it, I still believe this is a mis-feature for
Windows.

The other alternative is to put Python.exe on the network path, and
have your library in a ".\lib" directory under that.  Doesnt really
solve the problem for your "DragonLib" stuff - Im sure you dont want
to stuff _everything_ into a single .lib directory.

Also, IMO Python shouldnt bother going sniffing for its library if the
registry exists.  It just adds time to startup, and if it works is
almost guaranteed to be redundant, and if it doesnt work will add
useless entries that slow down module searches.  However, that still
doesnt solve your problem.

The final suggestion is to put some of the win32 extensions
(specifically, win32api) on a network share along with Python.exe and
the standard lib.  Then provide a .bat file that actually sets up the
registry, and off you go.  Sure, people hate the registry, but setting
an environment variable is worse.  Or an alternative - provide a .reg
file with the necessary registry keys - users can "execute" it
(double-clicking from explorer, typing the name in start->run, execute
"start whatever.reg in their logon script, etc) to have their registry
setup.

I wish I had a better answer, but can't for the life of me work out
what it should be even if MS supported it!


Mark.




From mal at lemburg.com  Fri Oct 15 10:34:14 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 15 Oct 1999 10:34:14 +0200
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <3806E706.82FEB673@lemburg.com>

Tim Peters wrote:
> 
> Python is getting used widely enough in my place of employment that people
> are agitating for a common installation (personal variants are screwing
> people too often).  Various machines are running Win95, Win98, NT,
> Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS.  I'll choke
> on that whole banana when it's shoved down my throat.
> 
> For starters, I just need to get it running across Windows platforms.  Never
> looked into this before, and it seems to be exceedingly complicated right
> out of the box <0.5 wink>:
> 
> D:\Python>python
> Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import sys
> ['',
>  'D:\\Python\\win32',
>  'D:\\Python\\win32\\lib',
>  'D:\\Python',
>  'D:\\Python\\Pythonwin',
>  'D:\\Python\\Lib\\plat-win',
>  'D:\\Python\\Lib',
>  'D:\\Python\\DLLs',
>  'D:\\Python\\Lib\\lib-tk',
>  'D:\\PYTHON\\DLLs',
>  'D:\\PYTHON\\lib',
>  'D:\\PYTHON\\lib\\plat-win',
>  'D:\\PYTHON\\lib\\lib-tk',
>  'D:\\PYTHON']
> >>>
> 
> Where does all that stuff come from?  The first is apparently the current
> directory; cool.  The next 4 appear to come from MarkH's stuff, via the
> registry.  The next 4 appear to come from Python's own registry PythonPath
> key.  The 4 after that are a mystery, and duplicate the preceding 4 (except
> for meaningless-- it's Windows <wink> -- case differences).  The last is
> another mystery.  site.py isn't implicated in any of them (same thing when
> running with -S).

On Linux I get:

['',
 '/home/lemburg/bin',
 '/home/lemburg/lib',
 '/home/lemburg/projects',
 '/home/lemburg/python/Lib/',
 '/home/lemburg/python/Lib/test',
 '/home/lemburg/python/Lib/plat-linux2',
 '/home/lemburg/python/Lib/lib-tk',
 '/home/lemburg/python/Modules',
 '/usr/local/lib/python1.5/site-packages']

It seems that the last entry refers to what Python thinks is the standard
location for system wide extensions. The first 3 come from my PYTHONPATH
setting, the next few are inserted by the Python startup code based
on what Python found as landmark to determine PYTHONHOME.

> I think this means I need to distribute a python15.dll and python.exe (via
> our source control system) into a directory very early on the PATH (other
> common .exe's are distributed this way, so no big deal), and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the
> common Dragon dir.

Sounds reasonable ;-)

> Network name mangling being what it is, I suppose I'll also need to force
> PYTHONCASEOK.  There's no way to do that from within Python, is there?  If
> not, everyone going through "unfortunate" paths in the network will have to
> set that themselves.

If Windows allows writing the process' environment you can set PYTHONCASEOK
dynamically: the check queries the environment for the flag prior
to every check (instead of doing going the usual internal Python flag
way as many of the others do). See Python/import.c:check_case() for details.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    77 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From jim at interet.com  Fri Oct 15 17:22:38 1999
From: jim at interet.com (James C. Ahlstrom)
Date: Fri, 15 Oct 1999 11:22:38 -0400
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <380746BE.FAE46A0A@interet.com>

Tim Peters wrote:
> ['',
>  'D:\\Python\\win32',
>  'D:\\Python\\win32\\lib',
>  'D:\\Python',
>  'D:\\Python\\Pythonwin',
>  'D:\\Python\\Lib\\plat-win',
>  'D:\\Python\\Lib',
>  'D:\\Python\\DLLs',
>  'D:\\Python\\Lib\\lib-tk',
>  'D:\\PYTHON\\DLLs',
>  'D:\\PYTHON\\lib',
>  'D:\\PYTHON\\lib\\plat-win',
>  'D:\\PYTHON\\lib\\lib-tk',
>  'D:\\PYTHON']
> >>>
> 
> Where does all that stuff come from?

Good question.  I don't know, and every time I start to
think I do, I am wrong.  Certainly PYTHONPATH is full of
junk on Windows.

The point is that PYTHONPATH just doesn't work for commercial
installations.  Please see these for some discussion:

  ftp://ftp.interet.com/bootmodule.html
  ftp://ftp.interet.com/pylib.html

I think the solution is to put the library
files and packages into archive files (in some format yet
to be determined) and find them by looking in the
directory of python15.dll and/or python.exe.   On Unix
there is $prefix, which actually seems to work.

> I think this means I need to distribute a python15.dll and python.exe (via
> our source control system) into a directory very early on the PATH

Yes, that is a good start.  Just understand that *.pyd and and DLL's
which are imported
(instead of linked against) are found from PYTHONPATH, not PATH.  Also
you will need a valid PATH on all PC's which is quite a bother.  An
alternative is to use the Wise installer to set up icons for your
apps.  Real Windows apps don't use PATH.  We use Wise for internal
as well as external apps.

Note that if you import a module "import foo", and foo
lives in "foo.dll", then on Windows, PYTHONPATH is searched, and
the standard Windows DLL path is not searched.  That means you
can't use standard Windows locations for DLL's which are dynamically
imported.  This is an error and should be fixed.

> and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk)

The problem is that you already need a valid PYTHONPATH to
find sitecustomize.py.  Better is to create a custom python15.dll
with sitecustomize.py, exceptions.py and site.py (all needed during
boot)
frozen in as frozen modules.  In our office I freeze in other library
files too.

> Network name mangling being what it is, I suppose I'll also need to force
> PYTHONCASEOK.

I don't seem to need that on 95/98/NT.  Network names shouldn't
get mangled on these systems.  I guess you mean lack of case
sensitivity, but just make sure the case is correct in the Lib
directory.  This is another reason to prefer archive files anyway.
But no, you shouldn't need PYTHONCASEOK.

> Anyone have better ideas?  That shouldn't be hard <wink>.

Yes, this is a major problem with Python's acceptance for
commercial apps (and I include internal production code as
an app) so lets figure out what to do and fix it.

Jim Ahlstrom



From jim at interet.com  Fri Oct 15 20:19:41 1999
From: jim at interet.com (James C. Ahlstrom)
Date: Fri, 15 Oct 1999 14:19:41 -0400
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com>
Message-ID: <3807703D.9FD09C5B@interet.com>

"James C. Ahlstrom" wrote:
Sorry, correct URL is:

   ftp://ftp.interet.com/pub/bootmodule.html
   ftp://ftp.interet.com/pub/pylib.htm

Jim Ahlstrom



From fredrik at pythonware.com  Fri Oct 15 21:17:05 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 15 Oct 1999 21:17:05 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com>
Message-ID: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>

while doing the final checks for my upcoming
standard library guide, I thought I'd check what
had changed in the CVS version.

some old (1.5.1) junk was still to be found in the
lib-old subdirectory, but certain 1.5.2 things seem
to have vanished into thin air.

like find.py, for example.  does anyone know
where it is?  after all, it's kinda useful, and I
just pointed someone to it, only to find that
he didn't have it on his machine...

is there an official list of totally deprecated
modules somewhere?

</F>




From fdrake at acm.org  Fri Oct 15 21:44:29 1999
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 15 Oct 1999 15:44:29 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
	<380746BE.FAE46A0A@interet.com>
	<3807703D.9FD09C5B@interet.com>
	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
Message-ID: <14343.33821.523179.786228@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > some old (1.5.1) junk was still to be found in the
 > lib-old subdirectory, but certain 1.5.2 things seem
 > to have vanished into thin air.
 > 
 > like find.py, for example.  does anyone know
 > where it is?  after all, it's kinda useful, and I

  It should be in lib-old.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From fredrik at pythonware.com  Fri Oct 15 21:58:17 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 15 Oct 1999 21:58:17 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim><380746BE.FAE46A0A@interet.com><3807703D.9FD09C5B@interet.com><006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us>
Message-ID: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>

Fred L. Drake, Jr. <fdrake at acm.org> wrote:
>  > like find.py, for example.  does anyone know
>  > where it is?  after all, it's kinda useful, and I
> 
>   It should be in lib-old.

"should" as in "is already there" or
"oops, I'll fix it" ? :-)

</F>

[fredrik at brain BleedingEdge]$ ls python/dist/src/Lib/lib-old/
CVS           codehack.py   newdir.py     rand.py       whatsound.py
Para.py       fmt.py        ni.py         tb.py         zmod.py
addpack.py    lockfile.py   poly.py       util.py

(sure looks like "oops" to me...)




From fdrake at acm.org  Fri Oct 15 22:41:14 1999
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 15 Oct 1999 16:41:14 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
	<380746BE.FAE46A0A@interet.com>
	<3807703D.9FD09C5B@interet.com>
	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
	<14343.33821.523179.786228@weyr.cnri.reston.va.us>
	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
Message-ID: <14343.37226.964388.867049@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > "should" as in "is already there" or
 > "oops, I'll fix it" ? :-)

  It's certainly in lib-old/ in the CVS repository.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From tismer at appliedbiometrics.com  Fri Oct 15 23:55:36 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 15 Oct 1999 23:55:36 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>
		<380746BE.FAE46A0A@interet.com>
		<3807703D.9FD09C5B@interet.com>
		<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
		<14343.33821.523179.786228@weyr.cnri.reston.va.us>
		<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us>
Message-ID: <3807A2D8.7E7F91F8@appliedbiometrics.com>


"Fred L. Drake, Jr." wrote:
> 
> Fredrik Lundh writes:
>  > "should" as in "is already there" or
>  > "oops, I'll fix it" ? :-)
> 
>   It's certainly in lib-old/ in the CVS repository.

Sorry. Definately certainly not.

But a find.py is in Demo/threads. 
Fred (any of both :) did you mean that?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From fredrik at pythonware.com  Mon Oct 18 09:31:16 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 18 Oct 1999 09:31:16 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>	<380746BE.FAE46A0A@interet.com>	<3807703D.9FD09C5B@interet.com>	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>	<14343.33821.523179.786228@weyr.cnri.reston.va.us>	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com>
Message-ID: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>

> >  > "should" as in "is already there" or
> >  > "oops, I'll fix it" ? :-)
> > 
> >   It's certainly in lib-old/ in the CVS repository.
> 
> Sorry. Definately certainly not.
> 
> But a find.py is in Demo/threads. 
> Fred (any of both :) did you mean that?

I cannot see any "find.py" in either Lib (where it
is in all my copies of 1.5.2) or Lib/lib-old.

fwiw, I can think of a few dozen other standard
library modules that I'd remove before this one.
cannot we put it back?  please? :-)

(after all, it's been a reoccuring theme on
comp.lang.python lately.  and 1.5.2+ breaks
my new book...).

</F>




From fdrake at acm.org  Mon Oct 18 16:31:34 1999
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 18 Oct 1999 10:31:34 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
	<380746BE.FAE46A0A@interet.com>
	<3807703D.9FD09C5B@interet.com>
	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
	<14343.33821.523179.786228@weyr.cnri.reston.va.us>
	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
	<14343.37226.964388.867049@weyr.cnri.reston.va.us>
	<3807A2D8.7E7F91F8@appliedbiometrics.com>
	<00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
Message-ID: <14347.12102.276497.310651@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > I cannot see any "find.py" in either Lib (where it
 > is in all my copies of 1.5.2) or Lib/lib-old.

  It most certainly *should* be appearing in lib-old; I just checked
the internal CVS repository and it's really there.  Perhaps the
anonymous mirror isn't right?
  (Barry, can you check this?  I don't even know where it is, much
less whether I can see those directories.)

 > fwiw, I can think of a few dozen other standard
 > library modules that I'd remove before this one.
 > cannot we put it back?  please? :-)

  That's up to Guido, not me.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From guido at CNRI.Reston.VA.US  Mon Oct 18 16:56:55 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 18 Oct 1999 10:56:55 -0400
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: Your message of "Mon, 18 Oct 1999 09:31:16 +0200."
             <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> 
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com>  
            <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> 
Message-ID: <199910181456.KAA22936@eric.cnri.reston.va.us>

> I cannot see any "find.py" in either Lib (where it
> is in all my copies of 1.5.2) or Lib/lib-old.

It *is* in Lib/lib-old.  Maybe the CVS mirror is messed up, we'll ask
Barry to investigate.  Maybe the branching messed things up?

> fwiw, I can think of a few dozen other standard
> library modules that I'd remove before this one.
> cannot we put it back?  please? :-)

It's better (and more illustrative) to use os.walk() to do this thing.

> (after all, it's been a reoccuring theme on
> comp.lang.python lately.  and 1.5.2+ breaks
> my new book...).

Good thing it isn't printed yet. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)



From bwarsaw at cnri.reston.va.us  Mon Oct 18 17:35:04 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Mon, 18 Oct 1999 11:35:04 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>
	<380746BE.FAE46A0A@interet.com>
	<3807703D.9FD09C5B@interet.com>
	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
	<14343.33821.523179.786228@weyr.cnri.reston.va.us>
	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
	<14343.37226.964388.867049@weyr.cnri.reston.va.us>
	<3807A2D8.7E7F91F8@appliedbiometrics.com>
	<00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
	<199910181456.KAA22936@eric.cnri.reston.va.us>
Message-ID: <14347.15912.178116.186186@anthem.cnri.reston.va.us>

>>>>> "Guido" == Guido van Rossum <guido at cnri.reston.va.us> writes:

    Guido> It *is* in Lib/lib-old.  Maybe the CVS mirror is messed up,
    Guido> we'll ask Barry to investigate.  Maybe the branching messed
    Guido> things up?

Somehow the mirror was out of date.  Perhaps the branch merge got it
out of whack, but in any case, I've done a top-level resync.  find.py
is definitely in the repository under lib-old now!

Hope that helps,
-Barry



From bwarsaw at cnri.reston.va.us  Tue Oct 19 17:30:01 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Tue, 19 Oct 1999 11:30:01 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Greg Rose
Message-ID: <14348.36473.112615.887932@anthem.cnri.reston.va.us>

Folks, I'm resending this message here for Greg Rose.  If anybody can
help him out, please respond to ggr at qualcomm.com (not to me).

Greg, if you still get no response, then I suggest sending the mssage
to greater python-list at python.org.  There's gotta be /somebody/ out
there who is interested in participating.

-Barry

------- start of forwarded message (RFC 934 encapsulation) -------
From: Greg Rose <ggr at qualcomm.com>
To: bwarsaw at python.org
Subject: Re: python advocate in Perl/Python/Tcl bakeoff
Date: Tue, 19 Oct 1999 20:28:37 +1000
X-Sender: ggr2 at avalon.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 

At 17:07 30/09/1999 -0400, you wrote:
>Hope that helps.  If neither of these guys can do it, and can't
>suggest someone who can, let me know and we'll post an announcement on 
>all the usual Python haunts.

Well, as they say, those who volunteer end up doing things...

I've tried both of your associates, and about three or four others who were
recommended, and have struck out. I'd really appreciate your help trying to
find someone competent to do this. Bear in mind that the audience is
sysadmins, not generic programmers.

thanks in advance,
Greg.

Here's the text I've been sending out, but you should feel free to modify
non-factual stuff:

Long ago there was a shell/perl/awk bakeoff invited talk at a USENIX
conference somewhere or other. It was fun for all involved, and was very
well received. We're looking to do something similar at the LISA conference
in Seattle. You have been recommended as Python advocate.

It would be on thursday 11th november. The idea would be to have a
moderator and three advocates, and a slightly rowdy audience. We'd ask each
advocate to nominate in advance some simple sysadmin task which shows their
language to its advantage, and also to do the solutions to the other two's
tasks... then there'd be some room for (presubmitted) tasks from the
audience to be solved on the fly. Any suggestions you have regarding how to
make it work would be appreciated.

Are you intending to attend LISA? Would you be willing to do this? (We have
Tom Christiansen for perl and Brent Welch for Tcl/Tk.)


Greg Rose                                     INTERNET: ggr at Qualcomm.com
Qualcomm Australia        VOICE:  +61-2-9181-4851   FAX: +61-2-9181-5470
Suite 410, Birkenhead Point,             http://people.qualcomm.com/ggr/ 
Drummoyne NSW 2047    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

------- end -------



From guido at CNRI.Reston.VA.US  Tue Oct 19 17:49:10 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Tue, 19 Oct 1999 11:49:10 -0400
Subject: [Python-Dev] forwarded message from Greg Rose
In-Reply-To: Your message of "Tue, 19 Oct 1999 11:30:01 EDT."
             <14348.36473.112615.887932@anthem.cnri.reston.va.us> 
References: <14348.36473.112615.887932@anthem.cnri.reston.va.us> 
Message-ID: <199910191549.LAA25773@eric.cnri.reston.va.us>

Alas, I'll be at SD99 East in DC that week, teaching Python CGI
programming.  See http://www.python.org/Events.html

--Guido van Rossum (home page: http://www.python.org/~guido/)




From da at ski.org  Tue Oct 19 18:58:34 1999
From: da at ski.org (David Ascher)
Date: Tue, 19 Oct 1999 09:58:34 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Irrelevant but very informative piece of patent law
Message-ID: <Pine.WNT.4.04.9910190955170.286-100000@rigoletto.ski.org>

http://slashdot.org/features/99/10/19/1032254.shtml

Very well written, too.  Many many standard deviations away from standard
slashdot fare.

--da




From mhammond at skippinet.com.au  Sat Oct 30 01:11:54 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 30 Oct 1999 09:11:54 +1000
Subject: [Python-Dev] Embedding Python when using different calling conventions.
Message-ID: <004201bf2262$fe5cfeb0$0501a8c0@bobcat>

This is a bit yucky, but still a valid problem.

Malte Kroeger [kroeger at bigfoot.com] recently posted to python-help
with a problem.  He has an existing Windows project that he wishes to
use Python in.  This project does not use the standard __cdecl calling
convention that Python uses, for various reasons known only to him.
As it is an existing project and quite probably a large, complex one,
I am willing to accept that moving his existing project to match
Python's calling convention is not reasonable.  I also feel for him,
as I have personally battled this - both with Python and with other
projects.

He has requested that Python explicitely declare the calling
convention it uses.  Thus, it can be embedded in any project.

He wants a new macro.  Eg:

DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *));
becomes
DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *));

I suggested embedding the calling convention in with the DL_IMPORT
macro, but he pointed out this macro is also used for variables, where
the convention syntax is illegal.

To my mind this is reasonable (maybe not the spelling, but definately
the intent).  Any thoughts?

Mark.




From mal at lemburg.com  Sat Oct 30 10:46:30 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 30 Oct 1999 10:46:30 +0200
Subject: [Python-Dev] Embedding Python when using different calling 
 conventions.
References: <004201bf2262$fe5cfeb0$0501a8c0@bobcat>
Message-ID: <381AB066.B54A47E0@lemburg.com>

Mark Hammond wrote:
> 
> This is a bit yucky, but still a valid problem.
> 
> Malte Kroeger [kroeger at bigfoot.com] recently posted to python-help
> with a problem.  He has an existing Windows project that he wishes to
> use Python in.  This project does not use the standard __cdecl calling
> convention that Python uses, for various reasons known only to him.
> As it is an existing project and quite probably a large, complex one,
> I am willing to accept that moving his existing project to match
> Python's calling convention is not reasonable.  I also feel for him,
> as I have personally battled this - both with Python and with other
> projects.

Isn't the default calling scheme selectable via compiler switches ?
I remember that this was the case with the IBM compiler on OS/2.
 
> He has requested that Python explicitely declare the calling
> convention it uses.  Thus, it can be embedded in any project.
> 
> He wants a new macro.  Eg:
> 
> DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *));
> becomes
> DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *));
> 
> I suggested embedding the calling convention in with the DL_IMPORT
> macro, but he pointed out this macro is also used for variables, where
> the convention syntax is illegal.

Perhaps switching to DL_IMPORT_FUNCTION(int) for functions would be a
better idea. This would leave the previous definition of DL_IMPORT
untouched (which is used by a few extensions too).

OTOH, we could take chance to reorganize these macros from bottom
up: when I started coding extensions I found them not very useful
mostly because I didn't have control over them meaning "export
this symbol" or "import the symbol". Especially the DL_IMPORT
macro is strange because it seems to handle both import *and*
export depending on whether Python is compiled or not.

FYI, I'm using these macros for the mx extensions:

/*
  Macros to control export and import of DLL symbols.

  We use our own definitions since Python's don't allow specifying
  both imported and exported symbols at the same time.

*/

/* Macro to "mark" a symbol for DLL export */

#if (defined(_MSC_VER) && _MSC_VER > 850		\
     || defined(__MINGW32__) || defined(__BEOS__))
# ifdef __cplusplus
#   define MX_EXPORT(type) extern "C" type __declspec(dllexport) 
# else
#   define MX_EXPORT(type) extern type __declspec(dllexport) 
# endif

#elif defined(__WATCOMC__)
#   define MX_EXPORT(type) extern type __export 

#else
#   define MX_EXPORT(type) extern type
#endif

/* Macro to "mark" a symbol for DLL import */

#if defined(__BORLANDC__)
#   define MX_IMPORT(type) extern type __import

#elif (defined(_MSC_VER) && _MSC_VER > 850		\
       || defined(__MINGW32__) || defined(__BEOS__))
# ifdef __cplusplus
#   define MX_IMPORT(type) extern "C" type __declspec(dllimport)
# else
#   define MX_IMPORT(type) extern type __declspec(dllimport)
# endif

#else
#   define MX_IMPORT(type) extern type
#endif

plus these kind of defines in the extension header files:

#ifdef MX_BUILDING_MXDATETIME
# define MXDATETIME_EXTERNALIZE MX_EXPORT
#else
# define MXDATETIME_EXTERNALIZE MX_IMPORT
#endif

Note that MX_EXPORT always defines export symbols and MX_IMPORT
always means "import the symbol". The *_EXTERNALIZE macro decides
which form to take depending on whether the header file is used
to compile the extension itself or using the extension.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    62 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From gmcm at hypernet.com  Sun Oct 31 16:59:16 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Sun, 31 Oct 1999 10:59:16 -0500
Subject: [Python-Dev] dircache.py
Message-ID: <1270737688-19939033@hypernet.com>

Pursuant to my volunteering to implement Guido's plan to 
combine cmp.py, cmpcache.py, dircmp.py and dircache.py 
into filecmp.py, I did some investigating of dircache.py.

I find it completely unreliable. On my NT box, the mtime of the 
directory is updated (on average) 2 secs after a file is added, 
but within 10 tries, there's always one in which it takes more 
than 100 secs (and my test script quits). My Linux box hardly 
ever detects a change within 100 secs.

I've tried a number of ways of testing this ("this" being 
checking for a change in the mtime of the directory), the latest 
of which is below. Even if dircache can be made to work 
reliably and surprise-free on some platforms, I doubt it can be 
done cross-platform. So I'd recommend that it just get dropped.

Comments?

---------------------------------------------------
import os
import sys
import time
d = os.getcwd()
atimes = []

def test():
    m = os.stat(d)[8]
    for i in range(10):
        fnm = 's%d.tmp' % i
        open(fnm,'w').write('dummy - delete me')
        for j in range(10000):
            newm = os.stat(d)[8]
            if newm != m:
                atimes.append(j*0.01)
                m = newm
                break
            time.sleep(0.01)
        else:
            print "At round %d, failed to detect add within %3.2f 
secs" % (i, j*0.01)
            break

def report():
    import operator
    if atimes:
        print "detect adds:   min= %3.2f max= %3.2f avg= 
%3.2f" % (min(atimes), max(atimes), reduce(operator.add, 
atimes, 0.0)/len(atimes))
    else:
        print "no successfully detected adds"

test()
report()

- Gordon



From mhammond at skippinet.com.au  Fri Oct  1 02:27:03 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 1 Oct 1999 10:27:03 +1000
Subject: [Python-Dev] getopt helper?
In-Reply-To: <14323.51267.54862.538939@anthem.cnri.reston.va.us>
Message-ID: <001601bf0ba3$b06ad770$0801a8c0@bobcat>

OK - general agreement.  Wheee :-)

How about this:

def getopt_or_die(opts,
                  long_opts=[],
                  usage=None,
                  prog_name=None,
                  args=None,
                  exit_code = 1):

if usage is None, we build a very simple usage string from
opts/long_opts.

If prog_name is None, we use os.path.basename(sys.argv[0]).  This is
printed just before the usage message.

If args is None, we use sys.argv[1:]

exit_code specifies the param to sys.exit() on invalid options.

I have based the ordering on my guess at the most likely to be used -
but maybe "prog_name" and "args" should be reversed?  This should
_not_ be all-singing, all-dancing, as it is simple to use the existing
getopt.getopt() directly for more esoteric requirements; the old 80-20
rule applies here :-)

If the general agreement continues, I will then knock together an
implementation.

Mark.




From gward at cnri.reston.va.us  Fri Oct  1 02:51:37 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Thu, 30 Sep 1999 20:51:37 -0400
Subject: [Python-Dev] getopt helper?
In-Reply-To: <001601bf0ba3$b06ad770$0801a8c0@bobcat>; from Mark Hammond on Fri, Oct 01, 1999 at 10:27:03AM +1000
References: <14323.51267.54862.538939@anthem.cnri.reston.va.us> <001601bf0ba3$b06ad770$0801a8c0@bobcat>
Message-ID: <19990930205136.A14297@cnri.reston.va.us>

On 01 October 1999, Mark Hammond said:
> OK - general agreement.  Wheee :-)
> 
> How about this:
> 
> def getopt_or_die(opts,
>                   long_opts=[],
>                   usage=None,
>                   prog_name=None,
>                   args=None,
>                   exit_code = 1):
> 
> if usage is None, we build a very simple usage string from
> opts/long_opts.

I still think it would be very desirable to tie the short and long
options together.  Eg.

  options = [('verbose', 'v'),
             ('quiet', 'q'),
             ('thingy', None),
             (None, 'x')
             ('output=', 'o:')]
  opts, args = getopt_or_die (options, usage, ...)

Then opts would have possible keys 'verbose', 'quiet', 'thingy', 'x',
and 'value' -- never 'v', 'q', or 'o'

(Look, I restrained my tendency to invent type systems and auto-generate
help text.  There may be hope for me yet.)

        Greg



From tim_one at email.msn.com  Fri Oct  1 07:55:46 1999
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 1 Oct 1999 01:55:46 -0400
Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports)
In-Reply-To: <199909181417.PAA20866@pukapuka.inrialpes.fr>
Message-ID: <000101bf0bd1$9b1cf5a0$842d153f@tim>

[Vladimir Marangozov, plugging]
> Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating
> Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978.

Wasn't Saltzer one of the CNRI fellows' advisors?  Jeremy's, perhaps?

it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs  - tim





From mhammond at skippinet.com.au  Sun Oct  3 09:52:59 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 3 Oct 1999 17:52:59 +1000
Subject: [Python-Dev] getopt helper?
In-Reply-To: <19990930205136.A14297@cnri.reston.va.us>
Message-ID: <001a01bf0d74$5031ed80$0801a8c0@bobcat>

Greg writes:
> I still think it would be very desirable to tie the short and long
> options together.  Eg.
>
>   options = [('verbose', 'v'),
>              ('quiet', 'q'),
>              ('thingy', None),
>              (None, 'x')
>              ('output=', 'o:')]
>   opts, args = getopt_or_die (options, usage, ...)
>

Im not convinced this is worth it.  I only use "long options" when I
have too many, or a few obscure ones.  I have never have "-v"
synonymous for "--verbose" - why bother?  I know I would never type
the later:-)

The existing mechanism still handles this quite well - the standard
"if opt==blah:" simply becomes "if opt in [...]:" - no real drag.

Plus its less change for reasonable reward - handy enough I may
actually add command-line handling as I create each little test/util
script :-)

What say anyone else?  Go with my "little change", Gregs "only
slightly more change" or "don't worry about it"?

Mark.




From skip at mojam.com  Sun Oct  3 16:26:54 1999
From: skip at mojam.com (Skip Montanaro)
Date: Sun, 3 Oct 1999 09:26:54 -0500 (CDT)
Subject: [Python-Dev] getopt helper?
In-Reply-To: <001a01bf0d74$5031ed80$0801a8c0@bobcat>
References: <19990930205136.A14297@cnri.reston.va.us>
	<001a01bf0d74$5031ed80$0801a8c0@bobcat>
Message-ID: <14327.26542.101415.144270@dolphin.mojam.com>

    Mark> Im not convinced this [pairing up long and short options] is worth
    Mark> it.

The primary reason where it would be helpful is to generate clearer default
usage strings.  Aside from that, I'm not sure the extra structure would be
worth it.

Skip



From jeremy at cnri.reston.va.us  Sun Oct  3 19:05:18 1999
From: jeremy at cnri.reston.va.us (Jeremy Hylton)
Date: Sun, 3 Oct 1999 13:05:18 -0400 (EDT)
Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports)
In-Reply-To: <000101bf0bd1$9b1cf5a0$842d153f@tim>
References: <199909181417.PAA20866@pukapuka.inrialpes.fr>
	<000101bf0bd1$9b1cf5a0$842d153f@tim>
Message-ID: <14327.36046.4763.670777@bitdiddle.cnri.reston.va.us>

>>>>> "TP" == Tim Peters <tim_one at email.msn.com> writes:

  TP> [Vladimir Marangozov, plugging]
  >> Saltzer J., "Naming and Binding of Objects", in Bayer R.,
  >> "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60,
  >> 1978.

  TP> Wasn't Saltzer one of the CNRI fellows' advisors?  Jeremy's,
  TP> perhaps?

Indeed he was.

  TP> it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim

I think sixth degrees of separation only made sense in the pre-email
world.  These days it's probably down to four or five.

Jeremy





From mhammond at skippinet.com.au  Mon Oct  4 01:30:25 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 4 Oct 1999 09:30:25 +1000
Subject: [Python-Dev] ESR on slashdot
Message-ID: <002001bf0df7$45e964b0$0801a8c0@bobcat>

Just as a matter of interest, here is a question put to ESR and his
answer.  We certainly could do alot worse than to have ESR becoming a
real Python advocate :-)  If only Guido himself could find time to
work on 1.6, we would be "in like Flynn" :-)

Mark.

shawnhargreaves asks:
You've always been involved in hacker projects outside of just coding
(eg. the Jargon File), but over the last year or so the spokesperson
role seems to have grown into a fulltime job. How long is it since you
last sat down to write a major piece of software? Do you expect to go
back to fulltime development work anytime soon, and if so, what would
you work on? How do you manage to cope with the withdrawal symptoms?

ESR answers:
An astute question ;-). I haven't sat down to write a major piece of
software from scratch in months, but I am continuing to maintain
fetchmail. I just took over the gif2png beta code with Greg Roelofs's
consent; the 1.0.0 version might be out by the time you read this.
Today I did some work on gnuplot, bringing the PNG driver up to date.

If I get to go full-time again soon, I want to go back to work on
Trove, the distributed web-based code-archiving system I designed last
year. I'd also like to work with Guido van Rossum on Python 1.6; there
are some long-time wishlist features like rich comparisons and a full
lambda facility that I care enough about to implement myself. I also
have a strategy-gaming system I wrote back in the 1980s that I'd like
to put a modern (Web-based) interface on. Finally, having contributed
a bit of code to GNOME (the network-monitor applet) I'd like to
balance things by doing something for KDE.




From gstein at lyra.org  Mon Oct  4 11:51:53 1999
From: gstein at lyra.org (Greg Stein)
Date: Mon, 4 Oct 1999 02:51:53 -0700 (PDT)
Subject: [Python-Dev] Alternative Approach to Relative Imports
In-Reply-To: <37F21B2F.DD65738F@interet.com>
Message-ID: <Pine.LNX.4.10.9910040248120.27657-100000@nebula.lyra.org>

On Wed, 29 Sep 1999, James C. Ahlstrom wrote:
> "M.-A. Lemburg" wrote:
> > I know, but there still is no way to query what kind of hooks
> > are already loaded and what is worse, you cannot unload or reorder
> > them.
> 
> I think this is a valid point.  I am interested in hooks to read
> modules from a file archive.  If you are a developer, it is
> necessary to turn this hook OFF, so that you can revert to the
> usual directory tree where your current source is.
> 
> I am solving this by leaving a global variable "Importer" in
> sitecustomize, and calling sitecustomize.Importer.enable(0).
> This works, but it might be useful if imputil could de-install
> a hook as well as install it.

It was a design point to not provide this functionality. It is pretty
difficult to unhook the importers from the chain. I specifically said,
"well... when you alter the import behavior, then it will stay that way."

I figured this was entirely safe since an Importer could have an
enable/disable flag like you implemented, or my (theoretical) Import
Manager could pull an Importer out of its list that it was managing.

I'm not sure that we want an Import Manager to always be installed in the
hooks, but it could be a good idea to have a standard manager in the
library somewhere (which Importers could state a dependency upon its
installation).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/





From jim at interet.com  Mon Oct  4 17:16:28 1999
From: jim at interet.com (James C. Ahlstrom)
Date: Mon, 04 Oct 1999 11:16:28 -0400
Subject: [Python-Dev] Alternative Approach to Relative Imports
References: <Pine.LNX.4.10.9910040248120.27657-100000@nebula.lyra.org>
Message-ID: <37F8C4CC.6C230B06@interet.com>

Greg Stein wrote:

> It was a design point to not provide this functionality. It is pretty
> difficult to unhook the importers from the chain. I specifically said,
> "well... when you alter the import behavior, then it will stay that way."
> 
> I figured this was entirely safe since an Importer could have an
> enable/disable flag like you implemented, or my (theoretical) Import
> Manager could pull an Importer out of its list that it was managing.

I think my design of leaving a global "Importer" instance variable
in imputil is a bit lame.  Each importer is a class instance, but I
don't see a list of importers in imputil.

Suppose impuil kept a list of installed importers
imputil.ImporterList[].
Then to access an importer I have installed, I can write:
    for im in imputil.ImporterList:
      if isinstance(im, MyImporter):
        im.enable(0)
It would not be necessary to dis-install an importer, imputil would
just undertake to keep a list of installed importers, and if someone
wanted to control their installed importers, they would use the list.

I do not feel too strongly about this.  Maybe it is a good idea.
What do you think?  I can just use my global variable I guess.

Jim Ahlstrom



From fredrik at pythonware.com  Wed Oct  6 11:52:55 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 6 Oct 1999 11:52:55 +0200
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
Message-ID: <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com>

http://www.cobolscript.com/

    "[COBOL's] just a language whose superiority for
    developing certain types of modern systems has
    been overlooked until now"

    PROCEDURE DIVISION.
           0000-MAIN.
           DISPLAY WEB-PAGE-HEADER.
           ACCEPT DATA FROM WEBPAGE.
           COMPUTE grand_total = subtotal *(1  sales_tax_rate).
           DISPLAY WEB-PAGE-BODY.
           DISPLAY WEB-PAGE-FOOTER.

well, why not? :-)

</F>




From jack at oratrix.nl  Wed Oct  6 13:02:39 1999
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 06 Oct 1999 13:02:39 +0200
Subject: [Python-Dev] an alternative language for CP4E, perhaps? 
In-Reply-To: Message by "Fredrik Lundh" <fredrik@pythonware.com> ,
	     Wed, 6 Oct 1999 11:52:55 +0200 , <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com> 
Message-ID: <19991006110240.068AC35BB1E@snelboot.oratrix.nl>

> http://www.cobolscript.com/
> 
>     "[COBOL's] just a language whose superiority for
>     developing certain types of modern systems has
>     been overlooked until now"

The whole site sort-of makes me wonder whether this is one big elaborate joke. 
But if it is somebody put an incredible amount of work in it.

The funny thing is that the idea of using Cobol for web-programming _did_ 
initially strike me as a neat idea: because of the elaborate data descriptions 
and report generation facilities you could conceivably use all that info to 
automatically generate all the input forms and such. But they have apparently 
done no such thing...

The timesheet example is, uhm, interesting. 1500 lines of code, with many 
parameters hardcoded in the source. I'd be surprised if it would take more 
than 100 lines in Python, with a lot more customizability too.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From guido at CNRI.Reston.VA.US  Wed Oct  6 16:57:21 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 06 Oct 1999 10:57:21 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: Your message of "Wed, 06 Oct 1999 13:02:39 +0200."
             <19991006110240.068AC35BB1E@snelboot.oratrix.nl> 
References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> 
Message-ID: <199910061457.KAA08749@eric.cnri.reston.va.us>

> X-Last-Band-Seen: Raggende Mannen afscheidsconcert (Paradiso, 4-10)
> X-Mini-Review: IK HEB HET OVERLEEFD! IK HEB HET OVERLEEFD! IK HEB HET 
>     OVERLEEFD!

Ach!  Wish I was there!

> > http://www.cobolscript.com/
> > 
> >     "[COBOL's] just a language whose superiority for
> >     developing certain types of modern systems has
> >     been overlooked until now"

> The whole site sort-of makes me wonder whether this is one big
> elaborate joke.  But if it is somebody put an incredible amount of
> work in it.

Definitely a joke.  Try

http://www.cobolscript.com/csfaq.htm#question9

"One of the other advantages of COBOL is that COBOL file processing
statements are very simple, with no knowledge of disk head positioning
required."

But yes, an incredibly good one!  Worth filling out the form on the
"contact us page" and seeing what they send back.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gmcm at hypernet.com  Wed Oct  6 18:55:18 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 6 Oct 1999 12:55:18 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: <199910061457.KAA08749@eric.cnri.reston.va.us>
References: Your message of "Wed, 06 Oct 1999 13:02:39 +0200."             <19991006110240.068AC35BB1E@snelboot.oratrix.nl> 
Message-ID: <1272894334-31005071@hypernet.com>

[Guido, on http://www.cobolscript.com/]

> Definitely a joke.  Try
> 
> http://www.cobolscript.com/csfaq.htm#question9
> 
> "One of the other advantages of COBOL is that COBOL file
> processing statements are very simple, with no knowledge of disk
> head positioning required."
> 
> But yes, an incredibly good one!  Worth filling out the form on
> the "contact us page" and seeing what they send back.

While funny, I can virtually guaruntee these people are serious.

It is a common misperception among mainframe/COBOL 
types that C/Unix has *only* character I/O (which does not 
exist in the former environment at all - even terminals are 
block I/O). They regard this as a sign of their vast superiority. 
(And I dearly wish that born-again "Windoze" bashers be 
sentenced to work in this environment - they'll soon realize 
how closely related Windows and Unix are).

I did a number of stints introducing client / server to Big Blue 
shops. (Unix made it's entry *only* because RDBMS's ran on 
them, and all these shops claimed they would dump Unix as 
soon as these products worked right on big iron). I *always* 
had an endless fight with the people who wanted to use 
COBOL instead of C / C++ (on both the Unix boxes and the 
PCs). 

MicroFocus distributed a "white paper" comparing COBOL to 
C that I came to know very, very well. It came in 4 sections:
- the Executive Summary said COBOL was vastly superior in 
all respects
- the White Paper said COBOL was more maintainable 
(translation - you can hire brown-nosing dorks in suits, instead 
of geeks in T-shirts) and often had superior performance
- the Benchmark showed that C smoked COBOL in absolutely 
everything except binary search (a COBOL builtin)
- the Appendix showed that the C code for "binary search" 
was a very badly coded linear search.

But no shop had ever read past the Executive Summary.

And don't forget that there is probably more than one order-of-
magnitude more COBOL source out there than source in any 
other (or maybe all other) language(s). All with no built-in date 
type; and hardly ever using common date routines either 
(calling external programs in COBOL is expensive, and 
awkward, because all variables are global).

Y2K-compliant-by-omission-ly y'rs

- Gordon



From guido at CNRI.Reston.VA.US  Wed Oct  6 19:00:50 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 06 Oct 1999 13:00:50 -0400
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: Your message of "Wed, 06 Oct 1999 10:57:21 EDT."
             <199910061457.KAA08749@eric.cnri.reston.va.us> 
References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl>  
            <199910061457.KAA08749@eric.cnri.reston.va.us> 
Message-ID: <199910061700.NAA09211@eric.cnri.reston.va.us>

Now I'm confused...  I typed in the comment box:

	Very good joke.  ROFL.
	Where do you guys find the
	time and energy to do this!
	:-)

and got this back:

	Mr. van Rossum

	Glad you took the time out of your busy schedule to berate us.
	We must be doing something right! ;)

	Chuck Shereda
	Deskware, Inc.
	www.deskware.com
	www.cobolscript.com

--Guido van Rossum (home page: http://www.python.org/~guido/)



From klm at digicool.com  Wed Oct  6 19:19:30 1999
From: klm at digicool.com (klm)
Date: Wed, 6 Oct 1999 13:19:30 -0400 (EDT)
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
In-Reply-To: <199910061700.NAA09211@eric.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.9910061316460.3705-100000@korak.digicool.com>

On Wed, 6 Oct 1999, Guido van Rossum wrote:

> Now I'm confused...  I typed in the comment box:
> 
> [...]
> and got this back:
> 
>       Mr. van Rossum
> 
>       Glad you took the time out of your busy schedule to berate us.
>       We must be doing something right! ;)
> 
>       Chuck Shereda
>       Deskware, Inc.
>       www.deskware.com
>       www.cobolscript.com
 
Apparently deskware is a known, bona fide organization.  Considering the
massive number of cobol programmers around, and despite how cumbersome the
prospect is (and with the advantage of factoring in the things gordon
said), i guess someone thinks there's leverage in making cobol a scripting
language.  I think it's not so different than making interpreted versions
of C (but i'm not very C friendly).

Ken
klm at digicool.com




From klm at digicool.com  Wed Oct  6 20:05:21 1999
From: klm at digicool.com (Ken Manheimer)
Date: Wed, 6 Oct 1999 14:05:21 -0400 
Subject: [Python-Dev] an alternative language for CP4E, perhaps?
Message-ID: <613145F79272D211914B0020AFF640191D1D2D@gandalf.digicool.com>

Concerning the possibility of cobolscript, i wrote:
 
> said), i guess someone thinks there's leverage in making cobol a
scripting
> language.  I think it's not so different than making interpreted
versions
> of C (but i'm not very C friendly).

After posting i thought this might come off as more ignorantly bigoted
than i meant for it to seem:-)  I was trying to say that C doesn't seem
very well suited to scripting/running interpreted, like cobol - not that
C is as fraught with ancient and awkward design as cobol (seems).

Sigh.

Ken
klm at digicool.com



From mal at lemburg.com  Mon Oct 11 22:36:07 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 11 Oct 1999 22:36:07 +0200
Subject: [Python-Dev] Walking up the package hierarchy
Message-ID: <38024A37.D92E7091@lemburg.com>

Hi everybody,

while I'm still thinking about writing the import manager, here
is a patch that implements the walk-up-the-hierarchy import scheme
that got so much positive feedback. I'm intending to use this
implementation as proof of concept for the switch to my new
package structure, but wouldn't mind seeing something like it
the distribution as well ;-)

It changes the default import mechanism to work like this:

>>> import d
try a.b.c.d
try a.b.d
try a.d
try d
fail

instead of just doing the current two-level lookup:

>>> import d
try a.b.c.d
try d
fail

As a result, relative imports referring to higher level packages
work out of the box without any ugly underscores in the import name.
Plus the whole scheme is pretty simple to explain and straightforward.

Since the patch is so small, I attached it to this mail. Hope
you don't mind. The ZIP archive also contains a sample package
which demonstrates the feature. Run Python with -v flag to see how
the new scheme works.

Feedback is most welcome. I am especially interested whether the
scheme breaks any existing packages.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    81 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: walkingimport.zip
Type: application/x-zip-compressed
Size: 2669 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/19991011/6ddcfec5/attachment-0001.bin>

From bwarsaw at cnri.reston.va.us  Tue Oct 12 22:21:02 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Tue, 12 Oct 1999 16:21:02 -0400 (EDT)
Subject: [Python-Dev] string methods branch
Message-ID: <14339.38958.882650.342925@anthem.cnri.reston.va.us>

Guido has agreed to let me mainline the string methods branch.  Those
of you on python-checkins should have seen the CVS messages by now.
This is a good thing because I think we can all agree we hate CVS
branches.  For me, that final merge put the nail in the coffin.

Anyway, those of you who have put off playing with string methods
until now should just be able to do a CVS update, rebuild, and go.
You should read the revision log messages for the branch checkins for
details of the changes.  Let me know if you have any problems.  Fred
and I will work out changes to the documentation some time soon.

>>> sig=['branches','are','only','useful','for','trees','and','streams','ly']
>>> print '-'.join(sig) + " y'rs"

-Barry



From skip at mojam.com  Tue Oct 12 23:03:13 1999
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 12 Oct 1999 16:03:13 -0500
Subject: [Python-Dev] new opportunities for obfuscation... ;-)
Message-ID: <199910122103.QAA31864@dolphin.mojam.com>

Barry's note prompted me to update my Python tree.  The result:

    >>> ".".join(dir(""))
    'capitalize.count.endswith.find.index.join.lower.lstrip.replace.rfind.rindex.rstrip.split.startswith.strip.swapcase.translate.upper'

A job well done, Barry...

Skip Montanaro | http://www.mojam.com/
skip at mojam.com | http://www.musi-cal.com/
847-971-7098   | Python: Programming the way Guido indented...



From mal at lemburg.com  Wed Oct 13 14:27:57 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 13 Oct 1999 14:27:57 +0200
Subject: [Python-Dev] Walking up the package hierarchy
References: <38024A37.D92E7091@lemburg.com>
Message-ID: <38047ACD.E716154E@lemburg.com>

Strange... I would have thought that this new patch would stir up
some cheers or opposition. Has anyone tried it in some real apps ?

It would be interesting to see whether it breaks any code in e.g.
packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't
break anything for my packages or apps.

> It changes the default import mechanism to work like this:
> 
> >>> import d
> try a.b.c.d
> try a.b.d
> try a.d
> try d
> fail
> 
> instead of just doing the current two-level lookup:
> 
> >>> import d
> try a.b.c.d
> try d
> fail

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    79 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From Vladimir.Marangozov at inrialpes.fr  Thu Oct 14 13:26:11 1999
From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov)
Date: Thu, 14 Oct 1999 12:26:11 +0100 (NFT)
Subject: [Python-Dev] Walking up the package hierarchy
In-Reply-To: <38047ACD.E716154E@lemburg.com> from "M.-A. Lemburg" at "Oct 13, 99 02:27:57 pm"
Message-ID: <199910141126.MAA32650@pukapuka.inrialpes.fr>

M.-A. Lemburg wrote:
> 
> Strange... I would have thought that this new patch would stir up
> some cheers or opposition. Has anyone tried it in some real apps ?

Not yet, but this looks better as a default search path.

> 
> It would be interesting to see whether it breaks any code in e.g.
> packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't
> break anything for my packages or apps.

JimF, /F, Guido and other package maintainers could do you a favor
by trying your patch ;-) and give us some real feedback on this.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



From tim_one at email.msn.com  Fri Oct 15 09:21:15 1999
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 15 Oct 1999 03:21:15 -0400
Subject: [Python-Dev] Corporate installations
Message-ID: <000401bf16dd$def75d80$d72d153f@tim>

Python is getting used widely enough in my place of employment that people
are agitating for a common installation (personal variants are screwing
people too often).  Various machines are running Win95, Win98, NT,
Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS.  I'll choke
on that whole banana when it's shoved down my throat.

For starters, I just need to get it running across Windows platforms.  Never
looked into this before, and it seems to be exceedingly complicated right
out of the box <0.5 wink>:

D:\Python>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
['',
 'D:\\Python\\win32',
 'D:\\Python\\win32\\lib',
 'D:\\Python',
 'D:\\Python\\Pythonwin',
 'D:\\Python\\Lib\\plat-win',
 'D:\\Python\\Lib',
 'D:\\Python\\DLLs',
 'D:\\Python\\Lib\\lib-tk',
 'D:\\PYTHON\\DLLs',
 'D:\\PYTHON\\lib',
 'D:\\PYTHON\\lib\\plat-win',
 'D:\\PYTHON\\lib\\lib-tk',
 'D:\\PYTHON']
>>>

Where does all that stuff come from?  The first is apparently the current
directory; cool.  The next 4 appear to come from MarkH's stuff, via the
registry.  The next 4 appear to come from Python's own registry PythonPath
key.  The 4 after that are a mystery, and duplicate the preceding 4 (except
for meaningless-- it's Windows <wink> -- case differences).  The last is
another mystery.  site.py isn't implicated in any of them (same thing when
running with -S).  I suppose this is a clue:

D:\Python>set PYTHONHOME=ick;fooey

D:\Python>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
>>> sys.path
['',
 'D:\\Python\\win32',
 'D:\\Python\\win32\\lib',
 'D:\\Python',
 'D:\\Python\\Pythonwin',
 'D:\\Python\\Lib\\plat-win',
 'D:\\Python\\Lib',
 'D:\\Python\\DLLs',
 'D:\\Python\\Lib\\lib-tk',
 'ick',
 'fooey\\DLLs',
 'ick',
 'fooey\\lib',
 'ick',
 'fooey\\lib\\plat-win',
 'ick',
 'fooey\\lib\\lib-tk',
 'D:\\PYTHON']
>>>

Doesn't appear to be sensible, but at least it's predictable <wink>.

I was surprised to find that setting PYTHONPATH can't be used to override
any of this -- it just inserts even more stuff, into sys.path[1:1].

Do I really care?  Not much -- the complexity just makes it hard to get a
mental model of what Python *thinks* it's trying to accomplish here, and so
harder to figure out what needs to be done.  Which is pretty severe:
"Dragon std" apps must run the same version of Python (which can be local)
with the same libraries (which must be network-mounted), regardless of
whatever version of Python each user may have built on their own, and
regardless of their registry settings or envar values.

I think this means I need to distribute a python15.dll and python.exe (via
our source control system) into a directory very early on the PATH (other
common .exe's are distributed this way, so no big deal), and add a
sitecustomize.py that replaces all of sys.path with the Big Four
(Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the
common Dragon dir.

Network name mangling being what it is, I suppose I'll also need to force
PYTHONCASEOK.  There's no way to do that from within Python, is there?  If
not, everyone going through "unfortunate" paths in the network will have to
set that themselves.

Anyone have better ideas?  That shouldn't be hard <wink>.

the-difference-between-one-user-and-two-is-infinite-ly y'rs  - tim





From mhammond at skippinet.com.au  Fri Oct 15 10:02:14 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 15 Oct 1999 18:02:14 +1000
Subject: [Python-Dev] Corporate installations
In-Reply-To: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <000101bf16e3$984577e0$0801a8c0@bobcat>

>  The 4 after that are a mystery, and duplicate the
> preceding 4 (except
> for meaningless-- it's Windows <wink> -- case differences).

Python makes a brave attempt to deduce the PYTHONHOME itself by
looking for "well-known" files in the lib directory.  Python15.dll
uses argv[0] or the result of GetModuleFileName(NULL) (whichever is
deemed "better" by the existance of a slash) as the basis for a search
for the landmark file.  If found, those 4 entries are added and if not
they are added relatively (ie ".\lib" in the vain hope they will
suddenly become meaningful (which they almost certainly wont)

So, when running a .EXE that lives in the main Python directory (such
as Python.exe), we get duplicated entries - the ones we deduced, and
the ones explicitely in the registry.

The problem arises when Python15.dll is used by a .exe that doesnt
live in this nice directory - eg Pythonwin, or any other embedding,
such as COM objects or peoples custom apps.  As argv[0] and
GetModuleFileName(NULL) both return a directory where "\lib" appended
will not find the landmark file (string.py for windows), you get the
useless relative paths added.

So, what this means is that Python's strategy for deducing the
PythonPath only works for Python.exe and Pythonw.exe - typically the
only .exes in the Python directory.  So we have the situation where
the paths must also be registered in the registry if any other .exe
wants to work.

> I was surprised to find that setting PYTHONPATH can't be used
> to override
> any of this -- it just inserts even more stuff, into sys.path[1:1].

Once upon a time Guido stated that PYTHONPATH should override the
registry completely.  I cant recall the history of this tho, and
wouldnt object is that was the case.  You are then faced with how to
set this env variable (and if you are doing that, why not just set the
registry?)

> I think this means I need to distribute a python15.dll and
> python.exe (via
> our source control system) into a directory very early on the
> PATH (other
> common .exe's are distributed this way, so no big deal), and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC
> paths, + the
> common Dragon dir.

This should be fine - as long as no one needs to run any other .EXE
that needs Python15.dll (or unless that other .exe is also in that
same directory).

> Network name mangling being what it is, I suppose I'll also
> need to force
> PYTHONCASEOK.  There's no way to do that from within Python,
> is there?  If

While my views on this have temepered from illogically ranting to
Guido how much I hate it, I still believe this is a mis-feature for
Windows.

The other alternative is to put Python.exe on the network path, and
have your library in a ".\lib" directory under that.  Doesnt really
solve the problem for your "DragonLib" stuff - Im sure you dont want
to stuff _everything_ into a single .lib directory.

Also, IMO Python shouldnt bother going sniffing for its library if the
registry exists.  It just adds time to startup, and if it works is
almost guaranteed to be redundant, and if it doesnt work will add
useless entries that slow down module searches.  However, that still
doesnt solve your problem.

The final suggestion is to put some of the win32 extensions
(specifically, win32api) on a network share along with Python.exe and
the standard lib.  Then provide a .bat file that actually sets up the
registry, and off you go.  Sure, people hate the registry, but setting
an environment variable is worse.  Or an alternative - provide a .reg
file with the necessary registry keys - users can "execute" it
(double-clicking from explorer, typing the name in start->run, execute
"start whatever.reg in their logon script, etc) to have their registry
setup.

I wish I had a better answer, but can't for the life of me work out
what it should be even if MS supported it!


Mark.




From mal at lemburg.com  Fri Oct 15 10:34:14 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 15 Oct 1999 10:34:14 +0200
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <3806E706.82FEB673@lemburg.com>

Tim Peters wrote:
> 
> Python is getting used widely enough in my place of employment that people
> are agitating for a common installation (personal variants are screwing
> people too often).  Various machines are running Win95, Win98, NT,
> Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS.  I'll choke
> on that whole banana when it's shoved down my throat.
> 
> For starters, I just need to get it running across Windows platforms.  Never
> looked into this before, and it seems to be exceedingly complicated right
> out of the box <0.5 wink>:
> 
> D:\Python>python
> Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import sys
> ['',
>  'D:\\Python\\win32',
>  'D:\\Python\\win32\\lib',
>  'D:\\Python',
>  'D:\\Python\\Pythonwin',
>  'D:\\Python\\Lib\\plat-win',
>  'D:\\Python\\Lib',
>  'D:\\Python\\DLLs',
>  'D:\\Python\\Lib\\lib-tk',
>  'D:\\PYTHON\\DLLs',
>  'D:\\PYTHON\\lib',
>  'D:\\PYTHON\\lib\\plat-win',
>  'D:\\PYTHON\\lib\\lib-tk',
>  'D:\\PYTHON']
> >>>
> 
> Where does all that stuff come from?  The first is apparently the current
> directory; cool.  The next 4 appear to come from MarkH's stuff, via the
> registry.  The next 4 appear to come from Python's own registry PythonPath
> key.  The 4 after that are a mystery, and duplicate the preceding 4 (except
> for meaningless-- it's Windows <wink> -- case differences).  The last is
> another mystery.  site.py isn't implicated in any of them (same thing when
> running with -S).

On Linux I get:

['',
 '/home/lemburg/bin',
 '/home/lemburg/lib',
 '/home/lemburg/projects',
 '/home/lemburg/python/Lib/',
 '/home/lemburg/python/Lib/test',
 '/home/lemburg/python/Lib/plat-linux2',
 '/home/lemburg/python/Lib/lib-tk',
 '/home/lemburg/python/Modules',
 '/usr/local/lib/python1.5/site-packages']

It seems that the last entry refers to what Python thinks is the standard
location for system wide extensions. The first 3 come from my PYTHONPATH
setting, the next few are inserted by the Python startup code based
on what Python found as landmark to determine PYTHONHOME.

> I think this means I need to distribute a python15.dll and python.exe (via
> our source control system) into a directory very early on the PATH (other
> common .exe's are distributed this way, so no big deal), and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the
> common Dragon dir.

Sounds reasonable ;-)

> Network name mangling being what it is, I suppose I'll also need to force
> PYTHONCASEOK.  There's no way to do that from within Python, is there?  If
> not, everyone going through "unfortunate" paths in the network will have to
> set that themselves.

If Windows allows writing the process' environment you can set PYTHONCASEOK
dynamically: the check queries the environment for the flag prior
to every check (instead of doing going the usual internal Python flag
way as many of the others do). See Python/import.c:check_case() for details.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    77 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/





From jim at interet.com  Fri Oct 15 17:22:38 1999
From: jim at interet.com (James C. Ahlstrom)
Date: Fri, 15 Oct 1999 11:22:38 -0400
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim>
Message-ID: <380746BE.FAE46A0A@interet.com>

Tim Peters wrote:
> ['',
>  'D:\\Python\\win32',
>  'D:\\Python\\win32\\lib',
>  'D:\\Python',
>  'D:\\Python\\Pythonwin',
>  'D:\\Python\\Lib\\plat-win',
>  'D:\\Python\\Lib',
>  'D:\\Python\\DLLs',
>  'D:\\Python\\Lib\\lib-tk',
>  'D:\\PYTHON\\DLLs',
>  'D:\\PYTHON\\lib',
>  'D:\\PYTHON\\lib\\plat-win',
>  'D:\\PYTHON\\lib\\lib-tk',
>  'D:\\PYTHON']
> >>>
> 
> Where does all that stuff come from?

Good question.  I don't know, and every time I start to
think I do, I am wrong.  Certainly PYTHONPATH is full of
junk on Windows.

The point is that PYTHONPATH just doesn't work for commercial
installations.  Please see these for some discussion:

  ftp://ftp.interet.com/bootmodule.html
  ftp://ftp.interet.com/pylib.html

I think the solution is to put the library
files and packages into archive files (in some format yet
to be determined) and find them by looking in the
directory of python15.dll and/or python.exe.   On Unix
there is $prefix, which actually seems to work.

> I think this means I need to distribute a python15.dll and python.exe (via
> our source control system) into a directory very early on the PATH

Yes, that is a good start.  Just understand that *.pyd and and DLL's
which are imported
(instead of linked against) are found from PYTHONPATH, not PATH.  Also
you will need a valid PATH on all PC's which is quite a bother.  An
alternative is to use the Wise installer to set up icons for your
apps.  Real Windows apps don't use PATH.  We use Wise for internal
as well as external apps.

Note that if you import a module "import foo", and foo
lives in "foo.dll", then on Windows, PYTHONPATH is searched, and
the standard Windows DLL path is not searched.  That means you
can't use standard Windows locations for DLL's which are dynamically
imported.  This is an error and should be fixed.

> and add a
> sitecustomize.py that replaces all of sys.path with the Big Four
> (Lib\plat-win, Lib, DLLs, and Lib\lib-tk)

The problem is that you already need a valid PYTHONPATH to
find sitecustomize.py.  Better is to create a custom python15.dll
with sitecustomize.py, exceptions.py and site.py (all needed during
boot)
frozen in as frozen modules.  In our office I freeze in other library
files too.

> Network name mangling being what it is, I suppose I'll also need to force
> PYTHONCASEOK.

I don't seem to need that on 95/98/NT.  Network names shouldn't
get mangled on these systems.  I guess you mean lack of case
sensitivity, but just make sure the case is correct in the Lib
directory.  This is another reason to prefer archive files anyway.
But no, you shouldn't need PYTHONCASEOK.

> Anyone have better ideas?  That shouldn't be hard <wink>.

Yes, this is a major problem with Python's acceptance for
commercial apps (and I include internal production code as
an app) so lets figure out what to do and fix it.

Jim Ahlstrom



From jim at interet.com  Fri Oct 15 20:19:41 1999
From: jim at interet.com (James C. Ahlstrom)
Date: Fri, 15 Oct 1999 14:19:41 -0400
Subject: [Python-Dev] Corporate installations
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com>
Message-ID: <3807703D.9FD09C5B@interet.com>

"James C. Ahlstrom" wrote:
Sorry, correct URL is:

   ftp://ftp.interet.com/pub/bootmodule.html
   ftp://ftp.interet.com/pub/pylib.htm

Jim Ahlstrom



From fredrik at pythonware.com  Fri Oct 15 21:17:05 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 15 Oct 1999 21:17:05 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com>
Message-ID: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>

while doing the final checks for my upcoming
standard library guide, I thought I'd check what
had changed in the CVS version.

some old (1.5.1) junk was still to be found in the
lib-old subdirectory, but certain 1.5.2 things seem
to have vanished into thin air.

like find.py, for example.  does anyone know
where it is?  after all, it's kinda useful, and I
just pointed someone to it, only to find that
he didn't have it on his machine...

is there an official list of totally deprecated
modules somewhere?

</F>




From fdrake at acm.org  Fri Oct 15 21:44:29 1999
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 15 Oct 1999 15:44:29 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
	<380746BE.FAE46A0A@interet.com>
	<3807703D.9FD09C5B@interet.com>
	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
Message-ID: <14343.33821.523179.786228@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > some old (1.5.1) junk was still to be found in the
 > lib-old subdirectory, but certain 1.5.2 things seem
 > to have vanished into thin air.
 > 
 > like find.py, for example.  does anyone know
 > where it is?  after all, it's kinda useful, and I

  It should be in lib-old.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From fredrik at pythonware.com  Fri Oct 15 21:58:17 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 15 Oct 1999 21:58:17 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim><380746BE.FAE46A0A@interet.com><3807703D.9FD09C5B@interet.com><006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us>
Message-ID: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>

Fred L. Drake, Jr. <fdrake at acm.org> wrote:
>  > like find.py, for example.  does anyone know
>  > where it is?  after all, it's kinda useful, and I
> 
>   It should be in lib-old.

"should" as in "is already there" or
"oops, I'll fix it" ? :-)

</F>

[fredrik at brain BleedingEdge]$ ls python/dist/src/Lib/lib-old/
CVS           codehack.py   newdir.py     rand.py       whatsound.py
Para.py       fmt.py        ni.py         tb.py         zmod.py
addpack.py    lockfile.py   poly.py       util.py

(sure looks like "oops" to me...)




From fdrake at acm.org  Fri Oct 15 22:41:14 1999
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 15 Oct 1999 16:41:14 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
	<380746BE.FAE46A0A@interet.com>
	<3807703D.9FD09C5B@interet.com>
	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
	<14343.33821.523179.786228@weyr.cnri.reston.va.us>
	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
Message-ID: <14343.37226.964388.867049@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > "should" as in "is already there" or
 > "oops, I'll fix it" ? :-)

  It's certainly in lib-old/ in the CVS repository.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From tismer at appliedbiometrics.com  Fri Oct 15 23:55:36 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 15 Oct 1999 23:55:36 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>
		<380746BE.FAE46A0A@interet.com>
		<3807703D.9FD09C5B@interet.com>
		<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
		<14343.33821.523179.786228@weyr.cnri.reston.va.us>
		<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us>
Message-ID: <3807A2D8.7E7F91F8@appliedbiometrics.com>


"Fred L. Drake, Jr." wrote:
> 
> Fredrik Lundh writes:
>  > "should" as in "is already there" or
>  > "oops, I'll fix it" ? :-)
> 
>   It's certainly in lib-old/ in the CVS repository.

Sorry. Definately certainly not.

But a find.py is in Demo/threads. 
Fred (any of both :) did you mean that?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From fredrik at pythonware.com  Mon Oct 18 09:31:16 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 18 Oct 1999 09:31:16 +0200
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>	<380746BE.FAE46A0A@interet.com>	<3807703D.9FD09C5B@interet.com>	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>	<14343.33821.523179.786228@weyr.cnri.reston.va.us>	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com>
Message-ID: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>

> >  > "should" as in "is already there" or
> >  > "oops, I'll fix it" ? :-)
> > 
> >   It's certainly in lib-old/ in the CVS repository.
> 
> Sorry. Definately certainly not.
> 
> But a find.py is in Demo/threads. 
> Fred (any of both :) did you mean that?

I cannot see any "find.py" in either Lib (where it
is in all my copies of 1.5.2) or Lib/lib-old.

fwiw, I can think of a few dozen other standard
library modules that I'd remove before this one.
cannot we put it back?  please? :-)

(after all, it's been a reoccuring theme on
comp.lang.python lately.  and 1.5.2+ breaks
my new book...).

</F>




From fdrake at acm.org  Mon Oct 18 16:31:34 1999
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 18 Oct 1999 10:31:34 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
References: <000401bf16dd$def75d80$d72d153f@tim>
	<380746BE.FAE46A0A@interet.com>
	<3807703D.9FD09C5B@interet.com>
	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
	<14343.33821.523179.786228@weyr.cnri.reston.va.us>
	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
	<14343.37226.964388.867049@weyr.cnri.reston.va.us>
	<3807A2D8.7E7F91F8@appliedbiometrics.com>
	<00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
Message-ID: <14347.12102.276497.310651@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > I cannot see any "find.py" in either Lib (where it
 > is in all my copies of 1.5.2) or Lib/lib-old.

  It most certainly *should* be appearing in lib-old; I just checked
the internal CVS repository and it's really there.  Perhaps the
anonymous mirror isn't right?
  (Barry, can you check this?  I don't even know where it is, much
less whether I can see those directories.)

 > fwiw, I can think of a few dozen other standard
 > library modules that I'd remove before this one.
 > cannot we put it back?  please? :-)

  That's up to Guido, not me.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From guido at CNRI.Reston.VA.US  Mon Oct 18 16:56:55 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 18 Oct 1999 10:56:55 -0400
Subject: [Python-Dev] what happened to find.py?
In-Reply-To: Your message of "Mon, 18 Oct 1999 09:31:16 +0200."
             <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> 
References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com>  
            <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> 
Message-ID: <199910181456.KAA22936@eric.cnri.reston.va.us>

> I cannot see any "find.py" in either Lib (where it
> is in all my copies of 1.5.2) or Lib/lib-old.

It *is* in Lib/lib-old.  Maybe the CVS mirror is messed up, we'll ask
Barry to investigate.  Maybe the branching messed things up?

> fwiw, I can think of a few dozen other standard
> library modules that I'd remove before this one.
> cannot we put it back?  please? :-)

It's better (and more illustrative) to use os.walk() to do this thing.

> (after all, it's been a reoccuring theme on
> comp.lang.python lately.  and 1.5.2+ breaks
> my new book...).

Good thing it isn't printed yet. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)



From bwarsaw at cnri.reston.va.us  Mon Oct 18 17:35:04 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Mon, 18 Oct 1999 11:35:04 -0400 (EDT)
Subject: [Python-Dev] what happened to find.py?
References: <000401bf16dd$def75d80$d72d153f@tim>
	<380746BE.FAE46A0A@interet.com>
	<3807703D.9FD09C5B@interet.com>
	<006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com>
	<14343.33821.523179.786228@weyr.cnri.reston.va.us>
	<000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com>
	<14343.37226.964388.867049@weyr.cnri.reston.va.us>
	<3807A2D8.7E7F91F8@appliedbiometrics.com>
	<00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com>
	<199910181456.KAA22936@eric.cnri.reston.va.us>
Message-ID: <14347.15912.178116.186186@anthem.cnri.reston.va.us>

>>>>> "Guido" == Guido van Rossum <guido at cnri.reston.va.us> writes:

    Guido> It *is* in Lib/lib-old.  Maybe the CVS mirror is messed up,
    Guido> we'll ask Barry to investigate.  Maybe the branching messed
    Guido> things up?

Somehow the mirror was out of date.  Perhaps the branch merge got it
out of whack, but in any case, I've done a top-level resync.  find.py
is definitely in the repository under lib-old now!

Hope that helps,
-Barry



From bwarsaw at cnri.reston.va.us  Tue Oct 19 17:30:01 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Tue, 19 Oct 1999 11:30:01 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Greg Rose
Message-ID: <14348.36473.112615.887932@anthem.cnri.reston.va.us>

Folks, I'm resending this message here for Greg Rose.  If anybody can
help him out, please respond to ggr at qualcomm.com (not to me).

Greg, if you still get no response, then I suggest sending the mssage
to greater python-list at python.org.  There's gotta be /somebody/ out
there who is interested in participating.

-Barry

------- start of forwarded message (RFC 934 encapsulation) -------
From: Greg Rose <ggr at qualcomm.com>
To: bwarsaw at python.org
Subject: Re: python advocate in Perl/Python/Tcl bakeoff
Date: Tue, 19 Oct 1999 20:28:37 +1000
X-Sender: ggr2 at avalon.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 

At 17:07 30/09/1999 -0400, you wrote:
>Hope that helps.  If neither of these guys can do it, and can't
>suggest someone who can, let me know and we'll post an announcement on 
>all the usual Python haunts.

Well, as they say, those who volunteer end up doing things...

I've tried both of your associates, and about three or four others who were
recommended, and have struck out. I'd really appreciate your help trying to
find someone competent to do this. Bear in mind that the audience is
sysadmins, not generic programmers.

thanks in advance,
Greg.

Here's the text I've been sending out, but you should feel free to modify
non-factual stuff:

Long ago there was a shell/perl/awk bakeoff invited talk at a USENIX
conference somewhere or other. It was fun for all involved, and was very
well received. We're looking to do something similar at the LISA conference
in Seattle. You have been recommended as Python advocate.

It would be on thursday 11th november. The idea would be to have a
moderator and three advocates, and a slightly rowdy audience. We'd ask each
advocate to nominate in advance some simple sysadmin task which shows their
language to its advantage, and also to do the solutions to the other two's
tasks... then there'd be some room for (presubmitted) tasks from the
audience to be solved on the fly. Any suggestions you have regarding how to
make it work would be appreciated.

Are you intending to attend LISA? Would you be willing to do this? (We have
Tom Christiansen for perl and Brent Welch for Tcl/Tk.)


Greg Rose                                     INTERNET: ggr at Qualcomm.com
Qualcomm Australia        VOICE:  +61-2-9181-4851   FAX: +61-2-9181-5470
Suite 410, Birkenhead Point,             http://people.qualcomm.com/ggr/ 
Drummoyne NSW 2047    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

------- end -------



From guido at CNRI.Reston.VA.US  Tue Oct 19 17:49:10 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Tue, 19 Oct 1999 11:49:10 -0400
Subject: [Python-Dev] forwarded message from Greg Rose
In-Reply-To: Your message of "Tue, 19 Oct 1999 11:30:01 EDT."
             <14348.36473.112615.887932@anthem.cnri.reston.va.us> 
References: <14348.36473.112615.887932@anthem.cnri.reston.va.us> 
Message-ID: <199910191549.LAA25773@eric.cnri.reston.va.us>

Alas, I'll be at SD99 East in DC that week, teaching Python CGI
programming.  See http://www.python.org/Events.html

--Guido van Rossum (home page: http://www.python.org/~guido/)




From da at ski.org  Tue Oct 19 18:58:34 1999
From: da at ski.org (David Ascher)
Date: Tue, 19 Oct 1999 09:58:34 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Irrelevant but very informative piece of patent law
Message-ID: <Pine.WNT.4.04.9910190955170.286-100000@rigoletto.ski.org>

http://slashdot.org/features/99/10/19/1032254.shtml

Very well written, too.  Many many standard deviations away from standard
slashdot fare.

--da




From mhammond at skippinet.com.au  Sat Oct 30 01:11:54 1999
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 30 Oct 1999 09:11:54 +1000
Subject: [Python-Dev] Embedding Python when using different calling conventions.
Message-ID: <004201bf2262$fe5cfeb0$0501a8c0@bobcat>

This is a bit yucky, but still a valid problem.

Malte Kroeger [kroeger at bigfoot.com] recently posted to python-help
with a problem.  He has an existing Windows project that he wishes to
use Python in.  This project does not use the standard __cdecl calling
convention that Python uses, for various reasons known only to him.
As it is an existing project and quite probably a large, complex one,
I am willing to accept that moving his existing project to match
Python's calling convention is not reasonable.  I also feel for him,
as I have personally battled this - both with Python and with other
projects.

He has requested that Python explicitely declare the calling
convention it uses.  Thus, it can be embedded in any project.

He wants a new macro.  Eg:

DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *));
becomes
DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *));

I suggested embedding the calling convention in with the DL_IMPORT
macro, but he pointed out this macro is also used for variables, where
the convention syntax is illegal.

To my mind this is reasonable (maybe not the spelling, but definately
the intent).  Any thoughts?

Mark.




From mal at lemburg.com  Sat Oct 30 10:46:30 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Sat, 30 Oct 1999 10:46:30 +0200
Subject: [Python-Dev] Embedding Python when using different calling 
 conventions.
References: <004201bf2262$fe5cfeb0$0501a8c0@bobcat>
Message-ID: <381AB066.B54A47E0@lemburg.com>

Mark Hammond wrote:
> 
> This is a bit yucky, but still a valid problem.
> 
> Malte Kroeger [kroeger at bigfoot.com] recently posted to python-help
> with a problem.  He has an existing Windows project that he wishes to
> use Python in.  This project does not use the standard __cdecl calling
> convention that Python uses, for various reasons known only to him.
> As it is an existing project and quite probably a large, complex one,
> I am willing to accept that moving his existing project to match
> Python's calling convention is not reasonable.  I also feel for him,
> as I have personally battled this - both with Python and with other
> projects.

Isn't the default calling scheme selectable via compiler switches ?
I remember that this was the case with the IBM compiler on OS/2.
 
> He has requested that Python explicitely declare the calling
> convention it uses.  Thus, it can be embedded in any project.
> 
> He wants a new macro.  Eg:
> 
> DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *));
> becomes
> DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *));
> 
> I suggested embedding the calling convention in with the DL_IMPORT
> macro, but he pointed out this macro is also used for variables, where
> the convention syntax is illegal.

Perhaps switching to DL_IMPORT_FUNCTION(int) for functions would be a
better idea. This would leave the previous definition of DL_IMPORT
untouched (which is used by a few extensions too).

OTOH, we could take chance to reorganize these macros from bottom
up: when I started coding extensions I found them not very useful
mostly because I didn't have control over them meaning "export
this symbol" or "import the symbol". Especially the DL_IMPORT
macro is strange because it seems to handle both import *and*
export depending on whether Python is compiled or not.

FYI, I'm using these macros for the mx extensions:

/*
  Macros to control export and import of DLL symbols.

  We use our own definitions since Python's don't allow specifying
  both imported and exported symbols at the same time.

*/

/* Macro to "mark" a symbol for DLL export */

#if (defined(_MSC_VER) && _MSC_VER > 850		\
     || defined(__MINGW32__) || defined(__BEOS__))
# ifdef __cplusplus
#   define MX_EXPORT(type) extern "C" type __declspec(dllexport) 
# else
#   define MX_EXPORT(type) extern type __declspec(dllexport) 
# endif

#elif defined(__WATCOMC__)
#   define MX_EXPORT(type) extern type __export 

#else
#   define MX_EXPORT(type) extern type
#endif

/* Macro to "mark" a symbol for DLL import */

#if defined(__BORLANDC__)
#   define MX_IMPORT(type) extern type __import

#elif (defined(_MSC_VER) && _MSC_VER > 850		\
       || defined(__MINGW32__) || defined(__BEOS__))
# ifdef __cplusplus
#   define MX_IMPORT(type) extern "C" type __declspec(dllimport)
# else
#   define MX_IMPORT(type) extern type __declspec(dllimport)
# endif

#else
#   define MX_IMPORT(type) extern type
#endif

plus these kind of defines in the extension header files:

#ifdef MX_BUILDING_MXDATETIME
# define MXDATETIME_EXTERNALIZE MX_EXPORT
#else
# define MXDATETIME_EXTERNALIZE MX_IMPORT
#endif

Note that MX_EXPORT always defines export symbols and MX_IMPORT
always means "import the symbol". The *_EXTERNALIZE macro decides
which form to take depending on whether the header file is used
to compile the extension itself or using the extension.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    62 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From gmcm at hypernet.com  Sun Oct 31 16:59:16 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Sun, 31 Oct 1999 10:59:16 -0500
Subject: [Python-Dev] dircache.py
Message-ID: <1270737688-19939033@hypernet.com>

Pursuant to my volunteering to implement Guido's plan to 
combine cmp.py, cmpcache.py, dircmp.py and dircache.py 
into filecmp.py, I did some investigating of dircache.py.

I find it completely unreliable. On my NT box, the mtime of the 
directory is updated (on average) 2 secs after a file is added, 
but within 10 tries, there's always one in which it takes more 
than 100 secs (and my test script quits). My Linux box hardly 
ever detects a change within 100 secs.

I've tried a number of ways of testing this ("this" being 
checking for a change in the mtime of the directory), the latest 
of which is below. Even if dircache can be made to work 
reliably and surprise-free on some platforms, I doubt it can be 
done cross-platform. So I'd recommend that it just get dropped.

Comments?

---------------------------------------------------
import os
import sys
import time
d = os.getcwd()
atimes = []

def test():
    m = os.stat(d)[8]
    for i in range(10):
        fnm = 's%d.tmp' % i
        open(fnm,'w').write('dummy - delete me')
        for j in range(10000):
            newm = os.stat(d)[8]
            if newm != m:
                atimes.append(j*0.01)
                m = newm
                break
            time.sleep(0.01)
        else:
            print "At round %d, failed to detect add within %3.2f 
secs" % (i, j*0.01)
            break

def report():
    import operator
    if atimes:
        print "detect adds:   min= %3.2f max= %3.2f avg= 
%3.2f" % (min(atimes), max(atimes), reduce(operator.add, 
atimes, 0.0)/len(atimes))
    else:
        print "no successfully detected adds"

test()
report()

- Gordon