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
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
implemen
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).
Y
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
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
>
> 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 parti
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
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/B
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 ea
>
>
>
> 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
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 applie
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
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
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 li
14 matches
Mail list logo
