Fredrik Lundh wrote:
well, from a performance perspective, it would be nice if Python looked
for *fewer* things, not more things.
Instead of searching for things by doing a stat call
for each possible file name, would it perhaps be
faster to read the contents of all the directories
along
Mike Orr wrote:
.abspath()
.normpath()
.realpath()
.splitpath()
.relpath()
.relpathto()
Seeing as the whole class is about paths, having
path in the method names seems redundant. I'd
prefer to see terser method names without any
noise characters in them.
--
Greg
Martin v. Löwis wrote:
That should never be better: the system will cache the directory
blocks, also, and it will do a better job than Python will.
If that's really the case, then why do discussions
of how improve Python startup speeds seem to focus
on the number of stat calls made?
Also,
Travis Oliphant wrote:
In NumPy, the data-type objects have function pointers to accomplish all
the things NumPy does quickly.
If the datatype object is to be extracted and made a
stand-alone feature, that might need to be refactored.
Perhaps there could be a facility for traversing a
Martin v. Löwis wrote:
A stat call will not only look at the directory entry, but also
look at the inode. This will require another disk access, as the
inode is at a different location of the disk.
That should be in favour of the directory-reading
approach, since e.g. to find out which if any
Armin Rigo wrote:
It would seem good practice to remove all .pycs
after checking out a new version of the source,
just in case there are other problems such as
mismatched timestamps, which can cause the same
trouble.
My two
cents is that it would be saner to have two separate concepts: cache
Delaney, Timothy (Tim) wrote:
Would it be reasonable to always do a stat() on the directory,
reloading if there's been a change? Would this be reliable across
platforms?
To detect a new shadowing you'd have to stat all the
directories along sys.path, not just the one you think
the file is
Martin v. Löwis wrote:
Currently, you can put a file on disk and import it
immediately; that will stop working.
One thing I should add is that if you try to import
a module that wasn't there before, the interpreter will
notice this and has the opportunity to update its idea
of what's on the
Martin v. Löwis wrote:
a) the directory cache is out of date, and you should
re-read the directory
b) the module still isn't there, but is available in
a later directory on sys.path (which hasn't yet
been visited)
c) the module isn't there at all, and the import will
eventually
Barry Warsaw wrote:
I'm not sure I like ~/.local though
- -- it seems counter to the app-specific dot-file approach old
schoolers like me are used to.
Problems with that are starting to show, though.
There's a particular Unix account that I've had for
quite a number of years, accumulating
Barry Warsaw wrote:
When I switched to OS X for most of my desktops, I had several
collisions in this namespace.
I think on MacOSX you have to consider that it's really
~/Documents and the like that are *your* namespaces,
rather than the top level of your home directory.
Also, I think
Steve Holden wrote:
So the subgroups are numbered starting from
1 and subgroup 0 is a special case which returns the whole match.
But the subgroups can be nested too, so it's
not really as special as all that.
--
Greg
___
Python-Dev mailing list
Nick Coghlan wrote:
*The inconsistency being that group() considers the whole match to be group
0,
while groups() does not.
The real inconsistency seems to be that the groups
are being treated as an array when they're really
a tree. Maybe a different API altogether would
be better, e.g.
Could backwards compatibility concerns be addressed
by including more than one version of Python in
the LSB? Python already allows multiple versions
to coexist, so applications targeting the LSB
would just need to be explicit about which version
of the interpreter to launch.
--
Greg
with threading, whereas the atexit mechanism could get
screwed up by someone who wasn't even thinking about
what effect it might have on threading.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem
Martin v. Löwis wrote:
Please
try to come up with a patch (e.g. by putting a while(is_tripped) loop
around the for loop).
That isn't going to fix it. What's needed is to somehow
atomically test and clear is_tripped at the beginning.
You can put a while loop around it as well if you want,
but
Nick Maclaren wrote:
This one looks like an oversight in Python code, and so is a bug,
but it is important to note that signals do NOT work reliably under
any Unix or Microsoft system.
That's a rather pessimistic way of putting it. In my
experience, signals in Unix mostly do what they're
Kristján V. Jónsson wrote:
(I was a bit dismayed that I couldn't assign to object.__init__
post-hoc from a python script, I'm fairly sure that is possible in Ruby :)
It wouldn't do you much good anyway, because no existing
subclass of object having its own __init__ method would
call it.
--
Martin v. Löwis wrote:
Greg Ewing schrieb:
Please
try to come up with a patch (e.g. by putting a while(is_tripped) loop
around the for loop).
That isn't going to fix it.
Why not?
Correct me if I'm wrong, but what I got from the OP
was that the current method does
if (is_tripped
unambiguous, and might be surprised if it gets turned
into a Windows path that's not.
In any case, there's no obvious meaning when going the other
way (i.e. translating C:\ into a Unix path). So I think
it's reasonable to say that translation of absolute paths
is not supported in general.
--
Greg
for both, or the Unix file
system must be mounted on the Windows system, in which case
they're both Windows paths. In neither case is a conversion
from Unix to Windows pathnames needed.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury
Michael O'Keefe wrote:
I'd like to see a built-in shorthand to allow me to
chain method calls even when a method call does not explicity
return a reference to the instance of the object (self).
def newFunc02():
return NewList([8,9,7,1]).self_('sort').self_('reverse').self_('pop',0)
My
[EMAIL PROTECTED] wrote:
I think there's room
for debate on whether specific list methods that currently return None should
instead return the list, although I would definitely consult the archives
before entering that fray.
Indeed. It's been discussed many times before.
It was a deliberate
Fabio Zadrozny wrote:
frame = findFrame(thread_id, frame_id)
exec '%s=%s' % (attr, expression) in frame.f_globals, frame.f_locals
The locals of a function are actually stored in an array.
When you access them as a dict using locals(), all you
get is a dict containing a copy of their current
Fabio Zadrozny wrote:
Would it be ok to add a feature request for that?
It seems a reasonable thing to suggest. Instead of
a copy, locals() could return a mapping object that
is a view of the underlying array. The only limitation
then would be that you couldn't add new keys.
I initially
Martin v. Löwis wrote:
It is the implementation of
foo **= bar
(and that's its only use), so it ought to be binary.
Maybe it's so that a type can plug the same implementation
into both nb_pow and nb_inplace_pow. Although the same
effect could be achieved by just leaving nb_inplace_pow
Martin v. Löwis wrote:
Greg Ewing schrieb:
Might we want to add an in-place version of the 3-arg
pow() function one day?
What could the syntax for that be?
It wouldn't be a syntax, just a function, e.g.
ipow(x, n, 10)
Also, it would break existing __ipow__ implementations
experience, the amount of code which truly needs
to use getattr is extremely small.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning
Georg Brandl wrote:
For the speed argument -- there were quite a few proposals to take builtins as
constants under certain conditions, in which case getattr() usage could be
optimized just as well as new syntax.
Even more aggressively, the compiler could recognise it
and make a direct call to
Ben North wrote:
Generally gently positive, with the exception of Anthony Baxter's
-1, which I understand to be motivated by concerns about newcomers to
the syntax
The more I think about it, the more I'm leaning
towards -1 as well. Adding syntax is a very big
step, and it needs a very solid
Richard Tew wrote:
The ideal mechanism at the high level would be expanding asyncore into
a one-stop shop. Where all these things can be passed into it and
it can do the work to notify of events on the objects in a standard way.
+1. This sounds like an excellent idea. It's downright
silly
Talin wrote:
What I am getting at is that rather that doing heroic efforts to add
stackless-ness to the current Python code base without changing it,
instead define a migration path which allows Python to eventually
acquire the characteristics of a stackless implementation.
I think you've
Josiah Carlson wrote:
def intern(st):
...
If I remember the implementation of intern correctly, that's more or
less what happens under the covers.
That doesn't quite give you everything that real interning
does, though. The string comparison method knows when both
strings are interned,
Brett Cannon wrote:
On 2/12/07, Collin Winter [EMAIL PROTECTED] wrote:
2) {BinOp,AugAssign,BoolOp,etc}.op
I can't think of a reason, off the top of my head, why they can't be
singletons.
Why not just use interned strings?
--
Greg
___
Python-Dev
Martin v. Löwis wrote:
Greg Ewing schrieb:
the end result would be too
convoluted for ordinary people to understand and maintain.
That very much depends on what the end result would be.
True. What I should have said is that Guido *believes*
the outcome would be too convoluted. Christian's
Martin v. Löwis wrote:
Apparently, people favor hasattr over catching
AttributeError. I'm not sure why this is - I would probably
rewrite them all to deal with AttributeError if I use the new
syntax in the first place.
Actually, I prefer using getattr with a default value over
either of
Martin v. Löwis wrote:
BTW, which of these would be correct
My thoughts would be
(a).[b] Okay
(a.)[b] Not okay
a.[(b)] Okay
a.([b]) Not okay
a . [ b ]Okay
and what is the semantics of
a.[42]
The same as getattr(a,
Steve Holden wrote:
I know that there's work in progress (and indeed
almost complete) to put Stackless into 2.5
It might be less confusing to rename the current version of
Stackless to microthreads or something, since it's not
really stackless at all.
--
Greg
Martin v. Löwis wrote:
OTOH, in an application that needs unique strings, you normally know
what the scope is (i.e. where the strings come from, and when they
aren't used anymore).
That's true -- if you know that all relevant strings have
been interned using the appropriate method, you can
Martin v. Löwis wrote:
OTOH, you can't write
x + = 2
or
a = 2 * * 4
Although oddly enough you *can* write
a[. . .]
I guess whoever added the ellipsis couldn't be bothered
defining a new token for it.
It's something of an arbitrary choice, but to me it just
seems that the
Guido van Rossum wrote:
it means we'll be catching AttributeError
instead of using look before you leap, which if fine with me.
A thought on this: to avoid masking bugs, when catching
AttributeError you really need to isolate the getattr
operation so that it's on a line by itself, with no
Ron Adam wrote:
Would it be possible for attrview to be a property?
To avoid polluting the namespace, it would need to have
a double-underscore name, and then it would be ugly to
use.
Unless we had a function to call it for you... oh,
wait, we've already got one -- it's called getattr. :-)
--
Josiah Carlson wrote:
In a recent
source checkout of the trunk Lib, there are 100+ uses of setattr, 400+
uses of getattr ... and a trivial number of delattr calls.
That's out of about 250,000 lines, or 0.2%.
Not a huge proportion, I would have thought.
--
Greg
Mike Klaas wrote:
As a comparison, enumerate (that I would have believed was much more
frequent a priori), is used 67 times, and zip/izip 165 times.
By that argument, we should be considering a special syntax
for zip and izip before getattr.
--
Greg
[EMAIL PROTECTED] wrote:
Given that you have more uses of zip/izip maybe we should be discussion
syntactic support for that instead. ;-)
I actually came up with an idea for that, slightly too
late to get considered in the original lockstep-iteration
debate:
for (x in seq1, y in seq2):
[EMAIL PROTECTED] wrote:
I have no problem with other, competing event-driven mechanisms being
developed;
The need for different event-driven mechanisms to compete
with each other is the very problem that needs to be
addressed.
If Twisted is designed so that it absolutely *has* to
use its own
Brett Cannon wrote:
Because the AST code at the C level represent the 'op' value as
basically an enumeration value, not a string. So creating an object
is somewhat easier then trying to do the conversion to an interned
string.
It would seem even easier (and a lot faster) to use an
array to
Guido van Rossum wrote:
But if we ever turn it into a single token (which we just may for
Py3k) don't complain if your code breaks.
I won't. I always treat it as a single token
anyway, unless I'm entering an obfuscated
python competition. :-)
--
Greg
Martin v. Löwis wrote:
Greg Ewing schrieb:
The string comparison method knows when both
strings are interned
No, it doesn't - see stringobject.c:string_richcompare.
Well, I'm surprised and confused.
It's certainly possible to tell very easily whether
a string is interned -- there's
Another thing I don't like about this default argument
proposal is that using it in any non-trivial way would
tend to put implementation details of the function
up in the header, which should be reserved for info
describing the calling signature.
The following example from the PEP is an extreme
Jean-Paul Calderone wrote:
Greg, productive discussion is not furthered by the
unsupported statement of one position or another.
Sorry, I'll expand on that a bit. The problem I
was referring to is the turf wars between all the
event-driven frameworks that all want to do things
their own way.
[EMAIL PROTECTED] wrote:
On 08:52 pm, [EMAIL PROTECTED] wrote:
When I last looked at twisted (that is several years ago), there were
several reactors - win32reactor, wxreactor, maybe even more.
Only the very top-most level decides which reactor the application will use.
This is a worry,
[EMAIL PROTECTED] wrote:
sounded like
monkeypatching the socket and asyncore modules to provide asynchronous
file I/O based on the platform-specific IOCP API for Windows.
I don't think anyone's suggesting that any long-term
solution to all this would involve monkeypatching.
--
Greg
Martin v. Löwis wrote:
switch(o) {
case And:
Py_INCREF(And_singleton);
return And_singleton;
case Or:
Py_INCREF(Or_singleton);
return Or_singleton;
Well,
Steve Holden wrote:
A further data point is that modern machines seem to give timing
variabilities due to CPU temperature variations even if you always eat
exactly the same thing.
Oh, great. Now we're going to have to run our
benchmarks in a temperature-controlled oven...
--
Greg
Martin v. Löwis wrote:
I think this would violate the policy that a mutating function shouldn't
give the object being modified as the result
Well, it's a necessary violation, given the way the inplace
methods work. And it doesn't *necessarily* return the same
value, it might return a new
Josiah Carlson wrote:
Assuming that dictionaries and the hash algorithm for strings is not
hopelessly broken, I believe that one discovers quite quickly when two
strings are not equal.
You're probably right, since if there's a hash collision,
the colliding strings probably differ in the first
Larry Hastings wrote:
If I understand your question correctly, you're saying why doesn't
string comparison take advantage of interned strings?
No, I understand that it takes advantage of it when the
strings are equal. I was wondering about the case where
they're not equal. But as has been
Steve Holden wrote:
If the borrowed code takes a reactor parameter then presumably the
top-level code can pass the appropriate reactor type in.
Since there should only be one reactor at a time in
any given application, it shouldn't have to be passed
in -- it could be held in a global variable
Thomas Wouters wrote:
If the choice for
reactor was made somewhere deep inside the library, how does it know to
use the GTK reactor?
In my ideal world, there wouldn't actually be a gtk
reactor -- there would only be a Linux reactor, a
MacOSX reactor, a Windows reactor, etc. Things like
Phillip J. Eby wrote:
peak.events, for example, lets you have multiple event loops
running in the same or different threads.
Different threads is okay if you're willing to use threads,
but you might not. The reason you're using an event loop
may well be precisely so that you *don't* have to
Thomas Wouters wrote:
If all (or all-but-one) of them have a 'run one iteration' method, you
can call that from the 'main' mainloop.
But without some way of blocking until an event arrives
for *either* loop, you have to resort to some kind of
busy polling, which is not elegant.
--
Greg
Thomas Wouters wrote:
*I* don't like the idea of something in the Python installation
deciding which reactor to use.
I wouldn't mind if some way were provided of changing
the reactor if you want. I'd just like to see a long
term goal of making it unnecessary as far as possible.
In any
Martin v. Löwis wrote:
That is insufficient. The gtk main loop has more input
sources than just the connection to X:
- timers
- idle handlers
- child handlers
- additional file descriptors
- a generalzed 'event source'
When gtk is not the central event mechanism, there's no
need to use
Oleg Broytmann wrote:
Given that they say a camel is a horse designed by a committee
BTW, camels are very suited for their environments...
The quote is actually a camel is a *racehorse* designed by a committee.
Camels are very good at surviving in the desert, but not so good at
winning a
Anthony Baxter wrote:
Unless the fans are perfectly balanced, small changes in gravity are
going to affect the rate at which they spin. So I guess the
position of the moon will affect it :-)
A standard gravitational field could also be important
to eliminate relativistic effects.
So we
Josiah Carlson wrote:
Somewhere in the back of my mind something is telling me - if you can
get a tuple with attributes based on __slots__, you just duplicate the
references as both an attribute AND in the standard tuple PyObject*
array,
It should be possible to start with a tuple subclass
Neal Becker wrote:
The fact that other numeric
types act this way leaves a reasonable expectation that bool will.
But bool isn't really a numeric type in the same way
that the others are. It's only a subtype of int for
historical reasons. If it had been a part of Python
from the beginning, it
Martin v. Löwis wrote:
One idiom that people use a lot is foo[b], where
b is a boolean.
Could that be addressed using the new __index__ mechanism?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
How would this change be helpful? I'm utterly mystified by these
suggestions that bool would be more useful if it didn't behave like an
int in arithmetic.
I think there's a desire by some people to get rid of
unnecessary conceptual baggage left over for historical
Stephen J. Turnbull wrote:
RKN = reverse Knuth numbering?wink
No, for RKN you'd have to start with 3141.5926... (an
infinite number of digits following) and drop one off
the end each time... although it would take rather a
long time to get to the final release then. :-(
--
Greg
Phillip J. Eby wrote:
At 03:38 PM 2/26/2007 -0700, Andrew Dalke wrote:
NO_END_OF_RECORD = ParserError(Cannot find end of record)
Then don't do that, as it's bad style for Python 3.x. ;-)
I don't like that answer. I can think of legitimate
reasons for wanting to pre-create exceptions, e.g.
[EMAIL PROTECTED] wrote:
Or modify __new__ on your particular heavily-optimized
exception to have a free-list,
Doing that in Python is likely to have as much overhead as
creating an instance.
The simple and obvious optimisation is to pre-create the
instance, but we're proposing to make the
Adam Olsen wrote:
It sounds like we should always copy the exception given to raise,
I don't like that either, for all the reasons that
make it infeasible to copy an arbitrary object in a
general way.
--
Greg
___
Python-Dev mailing list
instance
and then make a copy of it, unless this can be optimised
away somehow, and it's not necessarily obvious that the
refcount == 1 trick will work (it depends on the exact
details of how the references flow through the exception
raising machinery).
--
Greg Ewing, Computer Science Dept
creating one involves setting
up a dict, etc. And if you use __slots__ you end up with
objects of different sizes, which isn't free-list-friendly.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem
James Y Knight wrote:
It seems to me that a stack trace should always be attached to an
exception object at creation time
Um. Yes. Well, that's certainly an innovative solution...
The traceback won't necessarily be *useful*,
Almost completely use*less*, I would have thought.
The traceback
Michael Foord wrote:
With the
proposed changes, modules that do this would *continue* to work, surely
?
Probably, but it might mean they were no longer thread
safe. An exception caught and raised in one thread would
be vulnerable to having its traceback clobbered by
another thread raising
[EMAIL PROTECTED] wrote:
Perhaps the use-cases for attaching the traceback object
to the exception would be better satisfied by simply having
sys.exc_info() return an object with methods like Failure?
I can't think of a good name for the new object type,
Maybe we could call it a 'catch'
Brett Cannon wrote:
except Exception as exc with tb:
...
I was thinking of that too, plus a matching
raise Exception with tb
The only use for a 'catch' object would then be for
returning from sys.exc_info(), and I'm not sure it's
worth creating one just for that rather than using
a
Nick Maclaren wrote:
The instance contains all of the information about the details, such
as the exact operation, the values and the context (including the
traceback). It CAN'T be an object, because it is not 'assignable'
(i.e. a value) - it is inherently bound to its context. You can
turn
[EMAIL PROTECTED] wrote:
Why not just allow both exception classes and exception instances to be
raised, and only instantiate-at-catch in the case of a raise of a class
and a catch with an as clause?
Because that doesn't solve the problem of pre-instantiated
exceptions. What I'm proposing is
Collin Winter wrote:
Do those who oppose __traceback__ also oppose __cause__ and
__context__?
They would seem to have the same problems. Whatever
solution is adopted for the traceback should probably
be applied to them as well, perhaps by generalising
the traceback into an exception context
Michael Foord wrote:
Greg Ewing wrote:
An exception caught and raised in one thread would
be vulnerable to having its traceback clobbered by
another thread raising the same instance.
Right - but that would still be *no worse* than the current situation
where that information isn't
Guido van Rossum wrote:
I'm afraid we're back at square zero; perhaps we should keep the
existing (type, value, traceback) API
Whatever happens, we should be able to get that down
to at most two things: (exception, context) where
exception is either a class or an instance, and
context includes
Andrew Dalke wrote:
def __init__(self, prec=None, rounding=None,
traps=None, flags=None,
_rounding_decision=None,
Emin=None, Emax=None,
capitals=None, _clamp=0,
_ignored_flags=None):
...
Tim Lesher wrote:
FWIW, all of the standard Windows functions from the Microsoft CRT
(_splitpath) to the Shell API (PathRemoveExtension) to the CLR
(System.IO.Path.*) believe that .cshrc is the extension of the
filename .cshrc.
I'm not sure if that's an argument for or against the patch,
Nilton Volpato wrote:
If you open many member files concurrently how does file cache will
work? Or how many seeks you will have to do if you read from one
member file and from other alternatingly?
If the OS file system cache is doing its job properly,
I don't think the seeking should be a
Bill Janssen wrote:
If you really need a name other than timeout (which seems fine to
me), how about waiting-with-mild-trepidation-timeout?
Something like response timeout might be more descriptive.
--
Greg
___
Python-Dev mailing list
Martin v. Löwis wrote:
splitext(path)
Split the pathname path into a pair (root, ext) such that root + ext ==
path, and ext is empty or begins with a period and contains at most one
period.
Actually, that spec could be satisfied by a function
that *always* returned an empty string for
Collin Winter wrote:
Treat dates as if they have a time-part of midnight. This is my preferred
solution, and it is already what the datetime module does, for example,
when subtracting two dates.
Does it really? Seems to me you can pick any time of day
to be the representative time and get the
Jon Ribbens wrote:
So you're deciding that a 'date' is 'the entire of that day', except
when you subtract two of them, when it suddenly means something else? ;-)
No, you're considering dates to be discrete entities,
like integers. You wouldn't use the same reasoning to
argue that the
Jon Ribbens wrote:
What do you feel next Tuesday plus 12 hours means? ;-)
I would say it's meaningless. My feeling is that subtracting
two dates should give an integer number of days, and that is
all you should be allowed to add to a date.
--
Greg
Jon Ribbens wrote:
Steven Bethard [EMAIL PROTECTED] wrote:
We know that:
date(2006, 1, 1) *Includes* datetime(2006, 1, 1, 0, 0, 1)
Oh dear. You've fallen at the first hurdle. We do not know that.
Translated into English, this is saying The 1st of January
2006 includes the time one
Miguel Lobo wrote:
In fact I'm probably the person the
patch will benefit least, because I have already run into the problem
and know how to solve it.
For me, the personal benefit of getting a patch applied
would be so that I didn't have to keep re-applying it
to new versions of Python, and
Martin v. Löwis wrote:
I couldn't tell off-hand whether having
extension modules in a package would even work
It's quite common for a third-party package to consist
of some Python code and some extension modules, with
the extension modules living inside the package
namespace. It works fine.
--
Michael Urman wrote:
Who would rather see os.path.dropext(path)?
I'd like to see such a function, and also
maybe replaceext(path, new_ext). I often
end up coding things like these myself,
since indexing the result of splitext all
the time is rather ugly.
To round off the set, I suggest
Facundo Batista wrote:
are there processors that support reentrant interrupts?
The PDP11 had seven priority levels for interrupts.
When an interrupt was handled, interrupts with
priorities less than or equal to the current level
were blocked, but the handler could be interrupted
by a higher
[EMAIL PROTECTED] wrote:
Can you suggest any use-cases for thread termination which will *not*
result in a completely broken and unpredictable heap after the thread
has died?
Suppose you have a GUI and you want to launch a
long-running computation without blocking the
user interface. You
Mike Krell wrote:
I want
.emacs to be renamed to .1.emacs, thus preserving the extensions.
Under the new patch, the second file would be renamed to .emacs.1,
gratuitously breaking the extension preservation.
This argument presupposes that .emacs on its own
should be considered an extension,
601 - 700 of 2277 matches
Mail list logo
