[Python-Dev] mailbox._create_temporary without checking the file permission
Hi, guys.
_create_temporary is not tracking the perm bits of the original mbox.
$ ls -l me
-rw--- 1 dasn users 274886 Aug 16 08:43 me
$ python
Python 2.5.1 (r251:54863, May 8 2007, 07:32:21)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> from mailbox import mbox
>>> m=mbox('me')
>>> m.pop(0)
>>> m.flush()
>>>^D
$ ls -l me
-rwxr-xr-x 1 dasn users 268438 Aug 16 09:26 me*
$
--
Dasn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mailbox._create_temporary without checking the file permission
On 17/08/07 14:41 +0800, Dasn wrote:
>Hi, guys.
>
>_create_temporary is not tracking the perm bits of the original mbox.
>
>$ ls -l me
>-rw--- 1 dasn users 274886 Aug 16 08:43 me
>$ python
>Python 2.5.1 (r251:54863, May 8 2007, 07:32:21)
>[GCC 3.3.5 (propolice)] on openbsd4
>Type "help", "copyright", "credits" or "license" for more information.
from mailbox import mbox
m=mbox('me')
m.pop(0)
>
m.flush()
^D
>$ ls -l me
>-rwxr-xr-x 1 dasn users 268438 Aug 16 09:26 me*
>$
>
I think there are 2 problems should be considered in the _create_temporary:
1. what to do if we have no write permission to the directory (e.g.
/var/mail/), what about using tempfile module?
2. keep the temp file as the same mode as the original one.
--
Dasn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Documentation switch imminent
Georg Brandl wrote: >> Firefox, on my fairly recent machine, takes ~5 seconds rendering the >> index of the new docs from disk, compared to a fraction of a second >> for the old one. > > But you're right that rendering is slow there. It may be caused by the > more complicated CSS... perhaps the index should be split up in several > pages. Splitting out the C API index would probably be a reasonable start. (It may also be worth considering ignoring a leading Py or _Py in that index - many of the C API index entries end up under just two index groups). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Source file markers for Tru64?
I'm working on removing Tru64 support from the Python 3 code base. There aren't that many markers which actually say "Tru64". I see __digitial__ and OSF/1 as well. What others are there? Thx, Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Documentation switch imminent
On 8/17/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Alexandre Vassalotti schrieb:
> > On 8/16/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> >> On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> > Okay, I made the switch. I tagged the state of both Python branches
> >> > before the switch as tags/py{26,3k}-before-rstdocs/.
> >>
> >> http://docs.python.org/dev/
> >> http://docs.python.org/dev/3.0/
> >>
> >
> > Is it just me, or the markup of the new docs is quite heavy?
>
> Docutils markup tends to be a bit verbose, yes, but the index is not
> even generated by them.
>
> > alex% wget -q -O- http://docs.python.org/api/genindex.html | wc -c
> > 77868
> > alex% wget -q -O- http://docs.python.org/dev/3.0/genindex.html | wc -c
> > 918359
>
> The new index includes all documents (api, lib, ref, ...), so the ratio
> is more like 678000 : 95 (using 2.6 here), and the difference can be
> explained quite easily because (a) sphinx uses different anchor names
> ("mailbox.Mailbox.__contains__" vs "l2h-849") and the hrefs have to
> include subdirs like "reference/".
Ah, I didn't notice that index included all the documents. That
explains the huge size increase. However, would it be possible to keep
the indexes separated? I noticed that I find I want more quickly when
the indexes are separated.
> I've now removed leading spaces in the index output, and the character
> count is down to 85.
>
> > Firefox, on my fairly recent machine, takes ~5 seconds rendering the
> > index of the new docs from disk, compared to a fraction of a second
> > for the old one.
>
> But you're right that rendering is slow there. It may be caused by the
> more complicated CSS... perhaps the index should be split up in several
> pages.
>
I disabled CSS-support (with View->Page Style->No Style), but it
didn't affect the initial rendering speed. However, scrolling was
*much* faster without CSS.
-- Alexandre
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
[EMAIL PROTECTED] schrieb: > I'm working on removing Tru64 support from the Python 3 code base. Can you please add it to PEP 11 first? Please also add code that makes the build break in a version where the code is still in place, so that users can know that support for their platform is to be removed (in 3.0, I presume). > What others are there? Potentially, code that checks whether the processor is alpha might also be relevant - but that could also talk about other systems (Linux or VMS). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
Martin> [EMAIL PROTECTED] schrieb: >> I'm working on removing Tru64 support from the Python 3 code base. Martin> Can you please add it to PEP 11 first? Sorry, I was going by the Py3kDeprecated wiki page. Martin> Please also add code that makes the build break in a version Martin> where the code is still in place, so that users can know that Martin> support for their platform is to be removed (in 3.0, I presume). How do I do that? Does that go in the Python 2.6 code? >> What others are there? Martin> Potentially, code that checks whether the processor is alpha Martin> might also be relevant - but that could also talk about other Martin> systems (Linux or VMS). Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
> Martin> Can you please add it to PEP 11 first? > > Sorry, I was going by the Py3kDeprecated wiki page. Hmm. Who wrote this page, and why? I would hope that a PEP has more official status than a wiki page. > Martin> Please also add code that makes the build break in a version > Martin> where the code is still in place, so that users can know that > Martin> support for their platform is to be removed (in 3.0, I presume). > > How do I do that? Does that go in the Python 2.6 code? If you want to unsupport the system in 2.6, yes. You put something in configure.in which users can't fail to notice, e.g. a single-line abort that they need to uncomment before they can proceed. See earlier Python releases for how this was done (I would have to dig myself to find out what releases and what systems). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
According to the wiki history, BeOS was added to the wiki page by Skip. See http://wiki.python.org/moin/Py3kDeprecated?action=info (rev 6) On 8/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Martin> Can you please add it to PEP 11 first? > > > > Sorry, I was going by the Py3kDeprecated wiki page. > > Hmm. Who wrote this page, and why? I would hope that a PEP has more > official status than a wiki page. > > > Martin> Please also add code that makes the build break in a version > > Martin> where the code is still in place, so that users can know that > > Martin> support for their platform is to be removed (in 3.0, I presume). > > > > How do I do that? Does that go in the Python 2.6 code? > > If you want to unsupport the system in 2.6, yes. You put something in > configure.in which users can't fail to notice, e.g. a single-line abort > that they need to uncomment before they can proceed. See earlier Python > releases for how this was done (I would have to dig myself to find out > what releases and what systems). > > Regards, > Martin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation switch imminent
Alexandre Vassalotti wrote: > On 8/17/07, Georg Brandl <[EMAIL PROTECTED]> wrote: [...] > Ah, I didn't notice that index included all the documents. That > explains the huge size increase. However, would it be possible to keep > the indexes separated? I noticed that I find I want more quickly when > the indexes are separated. > Which is fine when you know which section to expect to find your content in. But let's retain an "all-documentation" index if we can, as this is particularly helpful to the newcomers who aren't that familiar with the structure of the documentation. >> I've now removed leading spaces in the index output, and the character >> count is down to 85. >> >>> Firefox, on my fairly recent machine, takes ~5 seconds rendering the >>> index of the new docs from disk, compared to a fraction of a second >>> for the old one. >> But you're right that rendering is slow there. It may be caused by the >> more complicated CSS... perhaps the index should be split up in several >> pages. >> > > I disabled CSS-support (with View->Page Style->No Style), but it > didn't affect the initial rendering speed. However, scrolling was > *much* faster without CSS. > Probably because the positional calculations are more straightforward then. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
Guido> According to the wiki history, BeOS was added to the wiki page by Guido> Skip. See http://wiki.python.org/moin/Py3kDeprecated?action=info Guido> (rev 6) I didn't make it up. I'm pretty sure I saw it somewhere in either the wiki, the python-3000 mailing list or in the source code itself. I'll dig around some and figure out where I found it. In the meantime, if someone else stumbles upon the smoking gun let me know. >> > Martin> Please also add code that makes the build break in a >> > Martin> version where the code is still in place, so that users >> > Martin> can know that support for their platform is to be >> > Martin> removed (in 3.0, I presume). >> > >> > How do I do that? Does that go in the Python 2.6 code? >> >> If you want to unsupport the system in 2.6, yes. You put something in >> configure.in which users can't fail to notice, e.g. a single-line >> abort that they need to uncomment before they can proceed. Thanks, I'll check out configure.in for that as well. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
I didn't make it up. I'm pretty sure I saw it somewhere in either the wiki, the python-3000 mailing list or in the source code itself. I'll dig around some and figure out where I found it. In the meantime, if someone else stumbles upon the smoking gun let me know. PEP 3100: Remove support for old systems, including: BeOS, RISCOS, (SGI) Irix, Tru64 I'll hold off on doing anything more until I can update PEP 11. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
Neal added it in rev 43214, when it was still PEP 3000. I'm sure he didn't read PEP 11 and beyond that I doubt he remembers from where he pulled this info. :-) On 8/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I didn't make it up. I'm pretty sure I saw it somewhere in either the > wiki, the python-3000 mailing list or in the source code itself. I'll > dig around some and figure out where I found it. In the meantime, if > someone else stumbles upon the smoking gun let me know. > > PEP 3100: > > Remove support for old systems, including: BeOS, RISCOS, (SGI) Irix, > Tru64 > > I'll hold off on doing anything more until I can update PEP 11. > > Skip > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Documentation switch imminent
It is fantastic! Totally super work. I just have one small request; pretty please do not set the font. I'm very happy with my browsers default (Verdana), and Bitstream Vera Sans renders badly for me. -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
Guido> Neal added it in rev 43214, when it was still PEP 3000. I'm sure Guido> he didn't read PEP 11 and beyond that I doubt he remembers from Guido> where he pulled this info. :-) Okay, next question. Have we documented somewhere the official maintainers of the various minor platforms (where that duty falls to one or a small group of people)? I realize for some platforms (Irix, Tru64/OSF/1/Digital Unix) it may not be a single person, but for others (OS/2, AtheOS, BeOS), it appears there is such a person. It would be nice information to collect if not. (Maybe as a section of PEP 11?) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
On 8/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Neal added it in rev 43214, when it was still PEP 3000. I'm sure he > didn't read PEP 11 and beyond that I doubt he remembers from where he > pulled this info. :-) When I added it in 43214, it was in an outstanding questions section. It wasn't meant to become gospel. :-) We have pretty crappy support for many versions of Unix. There are various problems with Solaris, AIX, HP-UX, etc. Not all the tests work on many of these platforms. When people report problems, they are almost always left unanswered. Since it's difficult to get access to boxes with the problems, our support isn't likely to improve. That was part of the motivation to consider removing the code. Another motivating factor was to eliminate code and make python easier to maintain. It may be reasonable that little used platforms are maintained as patches outside the core. VMS did this for a long time. I'm not sure if stock python has full VMS support or if there are still some patches necessary. Below are more details in case anyone cares. The checkin spawned this thread: http://mail.python.org/pipermail/python-dev/2006-March/062741.html One result was that we got a Tru64 buildbot out of it (which I have access to and help maintain). I'm not against keeping lesser platforms. But if they aren't used, they should be removed. Here is HP's support for Tru64: http://h30097.www3.hp.com/support.html The supported versions show the last released version was V5.1B-4 Dec 2006. HP still supports B-3 and B-4 for a minimum of 42 months from release (Jan 2005 for B-3). The end of support is still TBD for B-3 and B-4. n -- > > On 8/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > I didn't make it up. I'm pretty sure I saw it somewhere in either the > > wiki, the python-3000 mailing list or in the source code itself. I'll > > dig around some and figure out where I found it. In the meantime, if > > someone else stumbles upon the smoking gun let me know. > > > > PEP 3100: > > > > Remove support for old systems, including: BeOS, RISCOS, (SGI) Irix, > > Tru64 > > > > I'll hold off on doing anything more until I can update PEP 11. > > > > Skip > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source file markers for Tru64?
> Okay, next question. Have we documented somewhere the official maintainers > of the various minor platforms (where that duty falls to one or a small > group of people)? I realize for some platforms (Irix, Tru64/OSF/1/Digital > Unix) it may not be a single person, but for others (OS/2, AtheOS, BeOS), it > appears there is such a person. It would be nice information to collect if > not. (Maybe as a section of PEP 11?) Sounds fine to me. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
