[Python-Dev] Python 3 - Mac Installer?
Hi, Just wondered if/when there'd be a Mac installer for Python 3? Thanks! -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Programming in Python 3" - ISBN 0137129297 ___ 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] os.defpath for Windows
I can't see any logical reason for that. There should not be such a hack to avoid "magical bugs" when PATH is empty. On Sun, Dec 21, 2008 at 11:19 AM, Yinon Ehrlich wrote: > Hi, > > just saw that os.defpath for Windows is defined as >Lib/ntpath.py:30:defpath = '.;C:\\bin' > > Most Windows machines I saw has no c:\bin directory. > > Any reason why it was defined this way ? > Thanks, >Yinon > ___ > 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/techtonik%40gmail.com > -- --anatoly t. ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (12/19/08 - 12/26/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2295 open (+38) / 14279 closed (+12) / 16574 total (+50) Open issues with patches: 776 Average duration of open issues: 701 days. Median duration of open issues: 2752 days. Open Issues Breakdown open 2277 (+38) pending18 ( +0) Issues Created Or Reopened (51) ___ IDLE Code Caching Windows12/19/08 http://bugs.python.org/issue4691reopened amaury.forgeotdarc [PATCH] msvc9compiler raises IOError when no compiler found inst 12/19/08 http://bugs.python.org/issue4702created pjenvey patch Syntax error in sample code for enumerate in documentation. 12/20/08 CLOSED http://bugs.python.org/issue4703created trenholmes Update pybench for python 3.012/20/08 http://bugs.python.org/issue4704created marketdickinson patch python3.0 -u: unbuffered stdout 12/20/08 http://bugs.python.org/issue4705created haypo try to build a C module, but don't worry if it doesn't work 12/20/08 http://bugs.python.org/issue4706created zooko round() shows undocumented behaviour 12/20/08 http://bugs.python.org/issue4707created dingo patch os.pipe should return inheritable descriptors (Windows) 12/21/08 http://bugs.python.org/issue4708created castironpi Mingw-w64 and python on windows x64 12/21/08 http://bugs.python.org/issue4709created cdavid patch [PATCH] zipfile.ZipFile does not extract directories properly12/21/08 http://bugs.python.org/issue4710created faw patch Wide literals in the table of contents overflow in documentation 12/21/08 http://bugs.python.org/issue4711created scottdial Document pickle behavior for subclasses of dicts/lists 12/21/08 http://bugs.python.org/issue4712created georg.brandl Installing sgmlop can crash xmlrpclib12/21/08 http://bugs.python.org/issue4713created cito patch print opcode stats at the end of pybench runs12/21/08 http://bugs.python.org/issue4714created pitrou patch optimize bytecode for conditional branches 12/21/08 http://bugs.python.org/issue4715created pitrou patch Python 3.0 halts on shutdown when settrace is set12/22/08 http://bugs.python.org/issue4716created fabioz execfile conversion is not correct 12/22/08 CLOSED http://bugs.python.org/issue4717created fabioz wsgiref package totally broken 12/22/08 http://bugs.python.org/issue4718created hdima patch sys.exc_clear() not flagged in any way 12/22/08 CLOSED http://bugs.python.org/issue4719created fabioz Extension function optional argument specifica
Re: [Python-Dev] VM imaging based launch optimizations for CPython?
On Mon, Dec 22, 2008 at 12:09 PM, Erno Kuusela wrote: > > unexec probably work out of the box on symbian, but...: > > http://mail.python.org/pipermail/python-dev/2003-May/035727.html > > unexec() is pretty much what I was looking for. However, looks like its old hack from 80s and cannot be applied as is to the modern environment. Basically unexec() dumps the running application code (not specific to any interpreter) and data segments out as a.out binary. 1) Generating a binary file is not possible on Symbian and iPhone environments, because all binaries must be signed - however, we can probably use a generic stub exe which loads data segment only 2) a.out format is deprecated 3) Dynamic DLLs are not managed - basically a show stopper I hope I could find someone find enough OS fu to tell whether this is possible with DLLs at all and what data pointers must be patched on each unexec() call. -Mikko ___ 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] VM imaging based launch optimizations for CPython?
> > > > Of course, you still have the actual interpretation of > the top-level module code - if it's not the marshalling > but this part that actually costs performance, this > efficient marshalling algorithm won't help. It would be > interesting to find out which modules have a particularly > high startup cost - perhaps they can be rewritten I am afraid this is the case. I hope we could marshal an arbitary application state (not even Python specific) into a fast loading dump file (hibernation/snapshot). We have tried to use lazy importing as much as possible to distribute the importing cost across the application UI states. Out of my head I know at least two particular module which could be refactored. I'd recommend as the best practice that everything should be imported lazily if it's possible. However, looks like currently Python community is moving to another direction, since doing explict imports in __init__ etc. makes APIs cleaner (think Django) and debugging more sane task - Python is mainly used on the server and limited environments haven't been particular interesting until lately. logging - defines lots of classes which are used only if they are specified by logging options. I once hacked this for my personal use to be little lighter. urllib - particular heavy, imports httplib, ftplib and stuff even if it is not used Nokia has just released Python 2.5 based PyS60. I think we'll come back this after a while with a nice generic profiler which will tell the import cost. Merry XMas, -Mikko ___ 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] VM imaging based launch optimizations for CPython?
Mikko Ohtamaa wrote: > Out of my head I know at least two particular module which could be > refactored. I'd recommend as the best practice that everything should be > imported lazily if it's possible. We actually have a reason for discouraging lazy imports - using them carelessly makes it much easier to accidentally deadlock yourself on the import lock. I agree that this contributes to the problem of long startup times though. One sledgehammer approach to lazy imports is to modify the actual import system to use lazy imports by default, rather than having to explicitly enable them in a given module or for each particular import. Mercurial does this quite nicely by overriding the __import__ implementation [1]. Perhaps PyS60 could install something similar in site.py? The trade-off will be whether enough time is saved in avoiding "wasted" module loads to make up for the extra time spent managing the bookkeeping for the lazy imports. Cheers, Nick. [1] From a recent thread on Python-Ideas that Google found for me: http://selenic.com/repo/index.cgi/hg-stable/file/967adcf5910d/mercurial/demandimport.py#l1 -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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 3 - Mac Installer?
On Fri, Dec 26, 2008 at 2:55 AM, Mark Summerfield wrote: > Hi, > > Just wondered if/when there'd be a Mac installer for Python 3? I think there should be one eventually. Unfortunately, the 3.x build process is not ironed out. If somebody wants to make a patch which makes the build script in Mac/BuildScript/ work, I'd be very happy. :) > > Thanks! -- Regards, Benjamin Peterson ___ 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] A wart which should have been repaired in 3.0?
The doc for os.path.commonprefix states:
Return the longest path prefix (taken character-by-character) that is a
prefix of all paths in list. If list is empty, return the empty string
(''). Note that this may return invalid paths because it works a
character at a time.
I remember encountering this in an earlier version of Python 2.x (maybe 2.2
or 2.3?) and "fixed" it to work by pathname components instead of by
characters. That had to be reverted because it was a behavior change and
broke code which used it for strings which didn't represent paths. After
the reversion I then forgot about it.
I just stumbled upon it again. It seems to me this would have been a good
thing to fix in 3.0. Is this something which could change in 3.1 (or be
deprecated in 3.1 with deletion in 3.2)?
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] VM imaging based launch optimizations for CPython?
> Of course, you still have the actual interpretation of > the top-level module code - if it's not the marshalling > but this part that actually costs performance, this > efficient marshalling algorithm won't help. It would be > interesting to find out which modules have a particularly > high startup cost - perhaps they can be rewritten > > > I am afraid this is the case. Is that an unfounded or a founded fear? IOW, do you have hard numbers proving that it is the actual interpretation time (rather than the marshaling time) that causes the majority of the startup cost? > I hope we could marshal an arbitary > application state (not even Python specific) into a fast loading dump > file (hibernation/snapshot). I understand that this is what you want to get. I'm proposing that there might be a different approach to achieve a similar speedup. > logging - defines lots of classes which are used only if they are > specified by logging options. I once hacked this for my personal use to > be little lighter. So what speedup did you gain by rewriting it? (i.e. how many microseconds did "import logging" take before, how much afterwards?) How much of it was parsing/unmarshaling, and how much time byte code interpretation? Of the byte code interpretation, what opcodes in particular? > urllib - particular heavy, imports httplib, ftplib and stuff even if it > is not used Same questions here. This doesn't sound like any heavy computation is being done during startup. > Nokia has just released Python 2.5 based PyS60. I think we'll come back > this after a while with a nice generic profiler which will tell the > import cost. Looking forward to hear your numbers! 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] A wart which should have been repaired in 3.0?
s...@pobox.com wrote:
> The doc for os.path.commonprefix states:
>
> Return the longest path prefix (taken character-by-character) that is a
> prefix of all paths in list. If list is empty, return the empty string
> (''). Note that this may return invalid paths because it works a
> character at a time.
>
> I remember encountering this in an earlier version of Python 2.x (maybe 2.2
> or 2.3?) and "fixed" it to work by pathname components instead of by
> characters. That had to be reverted because it was a behavior change and
> broke code which used it for strings which didn't represent paths. After
> the reversion I then forgot about it.
>
> I just stumbled upon it again. It seems to me this would have been a good
> thing to fix in 3.0. Is this something which could change in 3.1 (or be
> deprecated in 3.1 with deletion in 3.2)?
Why can't we add an "allow_fragment" keyword that defaults to True? Then
"allow_fragment=False" will stop at the last full directory name and
ignore any partial matches on the filenames or the next subdirectory
(depending on where the common prefix ends).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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] A wart which should have been repaired in 3.0?
skip> I just stumbled upon it again. It seems to me this would have skip> been a good thing to fix in 3.0. Is this something which could skip> change in 3.1 (or be deprecated in 3.1 with deletion in 3.2)? Hmmm... I didn't really mean "deletion". I meant, could a behavior change be implemented in 3.2 with a warning emitted in 3.1? 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] A wart which should have been repaired in 3.0?
Nick> Why can't we add an "allow_fragment" keyword that defaults to Nick> True? Then "allow_fragment=False" will stop at the last full Nick> directory name and ignore any partial matches on the filenames or Nick> the next subdirectory (depending on where the common prefix ends). You could I suppose though that would just be adding another hack on top of existing questionable behavior. I wasn't so concerned with implementation as whether or not a change to the semantics of the function was possible. 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] A wart which should have been repaired in 3.0?
skip> I just stumbled upon it again. It seems to me this would have skip> been a good thing to fix in 3.0. Is this something which could skip> change in 3.1 (or be deprecated in 3.1 with deletion in 3.2)? This new issue in the tracker: http://bugs.python.org/issue4755 implements a commonpathprefix function. As explained in the submission this would be my second choice should it be decided that something should change. 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] A wart which should have been repaired in 3.0?
On Sat, 27 Dec 2008 10:58:07 am Nick Coghlan wrote:
> s...@pobox.com wrote:
> > The doc for os.path.commonprefix states:
> >
> > Return the longest path prefix (taken character-by-character)
> > that is a prefix of all paths in list. If list is empty, return the
> > empty string (''). Note that this may return invalid paths because
> > it works a character at a time.
> >
> > I remember encountering this in an earlier version of Python 2.x
> > (maybe 2.2 or 2.3?) and "fixed" it to work by pathname components
> > instead of by characters. That had to be reverted because it was a
> > behavior change and broke code which used it for strings which
> > didn't represent paths. After the reversion I then forgot about
> > it.
> >
> > I just stumbled upon it again. It seems to me this would have been
> > a good thing to fix in 3.0. Is this something which could change
> > in 3.1 (or be deprecated in 3.1 with deletion in 3.2)?
>
> Why can't we add an "allow_fragment" keyword that defaults to True?
> Then "allow_fragment=False" will stop at the last full directory name
> and ignore any partial matches on the filenames or the next
> subdirectory (depending on where the common prefix ends).
For what it's worth, I think that the two pieces of functionality are
different enough that in an ideal world they should be two different
functions rather than one function with a switch. I think
os.path.commonprefix should only operate on path components, and if
character-by-character prefix matching on general strings is useful,
then it should be a string method.
--
Steven D'Aprano
___
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
