----- 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 > *****************************************
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4