[Python-Dev] Re: Python-Dev Digest, Vol 4, Issue 33

Ding Yong dingy at shvns.com
Mon Nov 10 18:43:36 EST 2003


----- Original Message ----- 
From: <python-dev-request at python.org>
To: <python-dev at python.org>
Sent: Tuesday, November 11, 2003 12:57 AM
Subject: Python-Dev Digest, Vol 4, Issue 33


> Send Python-Dev mailing list submissions to
> python-dev at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/python-dev
> or, via email, send a message with subject or body 'help' to
> python-dev-request at python.org
>
> You can reach the person managing the list at
> python-dev-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-Dev digest..."
>
>
> Today's Topics:
>
>    1. python icons? (Matthias Klose)
>    2. tempfile.mktemp and os.path.exists (Iustin Pop)
>    3. RE: other "magic strings" issues (Delaney, Timothy C (Timothy))
>    4. Re: tempfile.mktemp and os.path.exists (Guido van Rossum)
>    5. Re: other "magic strings" issues (Alex Martelli)
>    6. Re: other "magic strings" issues (Michael Hudson)
>    7. Re: other "magic strings" issues (Michael Hudson)
>    8. Re: other "magic strings" issues (Skip Montanaro)
>    9. Re: other "magic strings" issues (Fred L. Drake, Jr.)
>   10. Re: other "magic strings" issues (Guido van Rossum)
>   11. Re: other "magic strings" issues (Guido van Rossum)
>   12. Re: other "magic strings" issues (Dan Sugalski)
>   13. Re: other "magic strings" issues (Michael Hudson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 9 Nov 2003 21:01:57 +0100
> From: Matthias Klose <doko at cs.tu-berlin.de>
> Subject: [Python-Dev] python icons?
> To: python-dev at python.org
> Message-ID: <16302.40245.488709.729747 at gargle.gargle.HOWL>
> Content-Type: text/plain; charset=us-ascii
>
> Wanting to add an icon for gnome/KDE menus for a binary python
> package. There are no images in the distribution itself, and not many
> on the website. Looking for something like
> http://www.python.org/cgi-bin/moinmoin/ in standard resolutions like
> 64x64, 48x48, 32x32 and 16x16. Maybe something like this could be
> added to the Misc directory in the tarball.
>
> Matthias
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 10 Nov 2003 00:44:45 +0200
> From: Iustin Pop <iusty at k1024.org>
> Subject: [Python-Dev] tempfile.mktemp and os.path.exists
> To: python-dev at python.org
> Message-ID: <20031109224445.GA26291 at saytrin.hq.k1024.org>
> Content-Type: text/plain; charset=us-ascii
>
> Hello,
>
> The tempfile.mktemp function uses os.path.exists to test whether a file
> already exists. Since this returns false for broken symbolic links,
> wouldn't it be better if the function would actually do an os.lstat on
> the filename?
>
> I know the function is not safe by definition, but this issue could
> (with a low probability) cause the file to actually be created in
> another directory, as the non-existent target of the symlink, instead of
> in the given directory (the one in which the symlink resides).
>
> Regards,
> Iustin Pop
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 10 Nov 2003 09:54:41 +1100
> From: "Delaney, Timothy C (Timothy)" <tdelaney at avaya.com>
> Subject: RE: [Python-Dev] other "magic strings" issues
> To: <python-dev at python.org>
> Message-ID:
> <338366A6D2E2CA4C9DAEAE652E12A1DEDF64B6 at au3010avexu1.global.avaya.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> > From: python-dev-bounces+tdelaney=avaya.com at python.org
> >
> > I guess the tests should be faster, yes, but I would still
> > want _iterables_ for ascii_*  and digits.
> >
> > One issue with allowing "if char in string.letters:" is that
> > these days this will not raise if the alleged 'char' is more
> > than one character -- it will give True for (e.g.) 'ab', False
> > for (e.g.) 'foobar', since it tests _substrings_.
>
> # inside string.py or equivalent ...
>
> import sets
>
> ascii_letters = sets.Set(ascii_letters)
>
> Hmm - we'd have the iterability, individual characters and speed, but lose
iterating in order. I'm sure there's things out there that rely on iterating
over ascii_letters in order ... ;)
>
> Tim Delaney
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 09 Nov 2003 18:11:57 -0800
> From: Guido van Rossum <guido at python.org>
> Subject: Re: [Python-Dev] tempfile.mktemp and os.path.exists
> To: Iustin Pop <iusty at k1024.org>
> Cc: python-dev at python.org
> Message-ID: <200311100211.hAA2BvK14648 at 12-236-54-216.client.attbi.com>
>
> > Hello,
> >
> > The tempfile.mktemp function uses os.path.exists to test whether a file
> > already exists. Since this returns false for broken symbolic links,
> > wouldn't it be better if the function would actually do an os.lstat on
> > the filename?
> >
> > I know the function is not safe by definition, but this issue could
> > (with a low probability) cause the file to actually be created in
> > another directory, as the non-existent target of the symlink, instead of
> > in the given directory (the one in which the symlink resides).
> >
> > Regards,
> > Iustin Pop
>
> Sounds like a good suggestion; I'll see if I can check something in.
>
> (However, given that there already exists an attack on this function,
> does fixing this actually make any difference?)
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 10 Nov 2003 09:18:15 +0100
> From: Alex Martelli <aleaxit at yahoo.com>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: "Delaney, Timothy C (Timothy)" <tdelaney at avaya.com>,
> <python-dev at python.org>
> Message-ID: <200311100918.15810.aleaxit at yahoo.com>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Sunday 09 November 2003 11:54 pm, Delaney, Timothy C (Timothy) wrote:
>    ...
> > ascii_letters = sets.Set(ascii_letters)
> >
> > Hmm - we'd have the iterability, individual characters and speed, but
lose
> > iterating in order. I'm sure there's things out there that rely on
> > iterating over ascii_letters in order ... ;)
>
> Yes, that's my main use case -- presenting results to the user, so they
need
> to be in alphabetic order (ascii_lowercase actually, but it's much the
same).
>
> Anyway, Guido has already pronounced on such enhancements as "Too
> Clever", so we have to keep ascii_lowercase &c as plain strings without
any
> enhancements and keep the "false positives" &c on 'in' checks.
>
>
> Alex
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 10 Nov 2003 10:34:40 +0000
> From: Michael Hudson <mwh at python.net>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: python-dev at python.org
> Message-ID: <2msmkwy0jj.fsf at starship.python.net>
> Content-Type: text/plain; charset=us-ascii
>
> Barry Warsaw <barry at python.org> writes:
>
> > I would love it if what happened really was something like:
> >
> >>>> from socket import *
> >>>> print AF_UNIX
> > socket.AF_UNIX
> >>>> from errno import *
> >>>> print EEXIST
> > errno.EEXIST
>
> I've had this idea too.  I like it, I think.  The signal module could
> use it too...
>
> Cheers,
> mwh
>
> -- 
>   I have a feeling that any simple problem can be made arbitrarily
>   difficult by imposing a suitably heavy administrative process
>   around the development.       -- Joe Armstrong, comp.lang.functional
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 10 Nov 2003 10:38:05 +0000
> From: Michael Hudson <mwh at python.net>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: python-dev at python.org
> Message-ID: <2moevky0du.fsf at starship.python.net>
> Content-Type: text/plain; charset=us-ascii
>
> Alex Martelli <aleaxit at yahoo.com> writes:
>
> > From Barry's discussion of the problem of "magic strings" as arguments
to
> > .encode / .decode , I was reminded of a blog entry,
> >
> > http://www.brunningonline.net/simon/blog/archives/000803.html
> >
> > which mentions another case of "magic strings" that might perhaps be
> > (optionally but suggestedly) changed into more-readable attributes (in
> > this case, clearly attributes of the 'file' type): mode arguments to
'file'
> > calls.  Simon Brunning, the author of that blog entry, argues that
> >
> > myFile = file(filename, 'rb')
> >
> > (while of course we're going to keep accepting it forever) is not quite
as
> > readable and maintainable as, e.g.:
> >
> > myFile = file(filename, file.READ + file.BINARY)
> >
> > Just curious -- what are everybody's feelings about that idea?  I'm
> > about +0 on it, myself -- I doubt I'd remember to use it (too much C
> > in my past...:-) but I see why others would prefer it.
>
> I think I prefer Guido's idea that when a function argument is almost
> always constant you should really have two functions and /F's (?)
> idea that there should be a 'textfile' function:
>
>     textfile(path[, mode='r'[, encoding='ascii']]) -> file object
>
> or similar.
>
> Cheers,
> mwh
>
> -- 
>   Need to Know is usually an interesting UK digest of things that
>   happened last week or might happen next week. [...] This week,
>   nothing happened, and we don't care.
>                            -- NTK Now, 2000-12-29, http://www.ntk.net/
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sat, 8 Nov 2003 06:34:07 -0600
> From: Skip Montanaro <skip at pobox.com>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: "Fred L. Drake, Jr." <fdrake at acm.org>
> Cc: Guido van Rossum <guido at python.org>, python-dev at python.org
> Message-ID: <16300.58047.526545.28711 at montanaro.dyndns.org>
> Content-Type: text/plain; charset=us-ascii
>
>
>     Fred> Frankly, that doesn't bother me, especially given that they've
>     Fred> always been in the string module.  But I count more than 4
>     Fred> constants that should be kept:
>
>     Fred>     ascii_letters
>     Fred>     ascii_lowercase
>     Fred>     ascii_uppercase
>     Fred>     digits
>     Fred>     hexdigits
>     Fred>     octdigits
>     Fred>     whitespace
>
> Don't forget 'punctuation'.  Maybe it should be 'ascii_punctuation', since
> I'm sure there are other punctuation characters which would turn up in
> unicode.
>
>     Fred> All of these could reasonably live on both str and unicode if
>     Fred> that's not considered pollution.  But if they live in a module,
>     Fred> there's no reason not to keep string around for that purpose.
>
> If they are going to be attached to a class, why not to basestring?
>
>     Fred> (I don't object to making them class attributes; I object to
creating
>     Fred> a new module for them.)
>
> Agreed.  If they stay in a module, I'd prefer they just stay in string.
> That creates the minimum amount of churn in people's code.  Anyone who's
> been converting to string methods has had to leave all the above constants
> alone anyway.
>
> Skip
>
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 10 Nov 2003 09:25:06 -0500
> From: "Fred L. Drake, Jr." <fdrake at acm.org>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: skip at pobox.com
> Cc: python-dev at python.org
> Message-ID: <16303.40898.410595.383833 at grendel.zope.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Skip Montanaro writes:
>  > Don't forget 'punctuation'.  Maybe it should be 'ascii_punctuation',
since
>  > I'm sure there are other punctuation characters which would turn up in
>  > unicode.
>
> Ah, yes.
>
>  > If they are going to be attached to a class, why not to basestring?
>
> That makes sense for ascii_* and *digits, perhaps.  whitespace and
> punctuation definately change for Unicode, so it's less clear that the
> values belong in a base class.
>
>
>   -Fred
>
> -- 
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Zope Corporation
>
>
>
> ------------------------------
>
> Message: 10
> Date: Mon, 10 Nov 2003 07:34:53 -0800
> From: Guido van Rossum <guido at python.org>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: Michael Hudson <mwh at python.net>
> Cc: python-dev at python.org
> Message-ID: <200311101534.hAAFYrB15503 at 12-236-54-216.client.attbi.com>
>
> > > I would love it if what happened really was something like:
> > >
> > >>>> from socket import *
> > >>>> print AF_UNIX
> > > socket.AF_UNIX
> > >>>> from errno import *
> > >>>> print EEXIST
> > > errno.EEXIST
> >
> > I've had this idea too.  I like it, I think.  The signal module could
> > use it too...
>
> Yes, that would be cool for many enums.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>
>
> ------------------------------
>
> Message: 11
> Date: Mon, 10 Nov 2003 07:39:07 -0800
> From: Guido van Rossum <guido at python.org>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: Michael Hudson <mwh at python.net>
> Cc: python-dev at python.org
> Message-ID: <200311101539.hAAFd8H15525 at 12-236-54-216.client.attbi.com>
>
> > I think I prefer Guido's idea that when a function argument is almost
> > always constant you should really have two functions and /F's (?)
> > idea that there should be a 'textfile' function:
> >
> >     textfile(path[, mode='r'[, encoding='ascii']]) -> file object
> >
> > or similar.
>
> I'm not so sure about that in this case.  There are quite a few places
> where one writes a wrapper for open() that takes a mode and passes it
> on to the real open().  Having to distinguish between multiple open()
> functions would complexify this.
>
> OTOH my experimental standard I/O replacement (nondist/sandbox/sio)
> does a similar thing, by providing different constructors for
> different functionality (buffering, text translation, low-level I/O
> basis).
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>
>
> ------------------------------
>
> Message: 12
> Date: Mon, 10 Nov 2003 10:44:56 -0500 (EST)
> From: Dan Sugalski <dan at sidhe.org>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: "Fred L. Drake, Jr." <fdrake at acm.org>
> Cc: skip at pobox.com, python-dev at python.org
> Message-ID: <Pine.LNX.4.58.0311101043300.15737 at sprite.sidhe.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Mon, 10 Nov 2003, Fred L. Drake, Jr. wrote:
>
> >
> > Skip Montanaro writes:
> >  > Don't forget 'punctuation'.  Maybe it should be 'ascii_punctuation',
since
> >  > I'm sure there are other punctuation characters which would turn up
in
> >  > unicode.
> >
> > Ah, yes.
> >
> >  > If they are going to be attached to a class, why not to basestring?
> >
> > That makes sense for ascii_* and *digits, perhaps.
>
> Digits change for Unicode as well. Plus they get potentially...
> interesting in some cases, where the digit-ness of a character is arguably
> contextually driven, but I think that can be ignored. Most of the time, at
> least.
>
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski                          even samurai
> dan at sidhe.org                         have teddy bears and even
>                                       teddy bears get drunk
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Mon, 10 Nov 2003 15:56:01 +0000
> From: Michael Hudson <mwh at python.net>
> Subject: Re: [Python-Dev] other "magic strings" issues
> To: python-dev at python.org
> Message-ID: <2md6c0xlny.fsf at starship.python.net>
> Content-Type: text/plain; charset=us-ascii
>
> Guido van Rossum <guido at python.org> writes:
>
> >> I think I prefer Guido's idea that when a function argument is almost
> >> always constant you should really have two functions and /F's (?)
> >> idea that there should be a 'textfile' function:
> >>
> >>     textfile(path[, mode='r'[, encoding='ascii']]) -> file object
> >>
> >> or similar.
> >
> > I'm not so sure about that in this case.  There are quite a few places
> > where one writes a wrapper for open() that takes a mode and passes it
> > on to the real open().
>
> I may just be being thick today but I can't think of many.  Most of
> the time passing in an already on file object would be better
> interface, surely?  Well, there's things like the codec writers, but
> textfile would hopefully subsume them.
>
> > Having to distinguish between multiple open() functions would
> > complexify this.
> >
> > OTOH my experimental standard I/O replacement (nondist/sandbox/sio)
> > does a similar thing, by providing different constructors for
> > different functionality (buffering, text translation, low-level I/O
> > basis).
>
> Does text translation cover unicode issues here?
>
> Cheers,
> mwh
>
> -- 
>   Never meddle in the affairs of NT. It is slow to boot and quick to
>   crash.                                             -- Stephen Harris
>                -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
>
>
>
> ------------------------------
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
>
>
> End of Python-Dev Digest, Vol 4, Issue 33
> *****************************************




More information about the Python-Dev mailing list