At 07:47 PM 10/19/2005 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
Note that a where or given statement like this could make it a
little easier to drop lambda.
I think the lambda will disappear in Py3k concept might have been what
triggered the original 'where' statement discussion
At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote:
callable name tuple:
definitions
...
Steve Wow, that's really neat. And you save a keyword! ;-)
Two if you add a builtin called function (get rid of def).
Not unless the tuple is passed in as an abstract syntax
At 12:46 PM 10/19/2005 -0700, Josiah Carlson wrote:
[EMAIL PROTECTED] wrote:
Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip Not unless the tuple is passed in as an abstract syntax
tree or
Phillip something.
Hmmm... Maybe I misread something then. I saw (I think
At 07:30 PM 10/19/2005 -0700, Josiah Carlson wrote:
What about a situation in which corutines are handled by multiple
threads? Any time a corutine passed from one thread to another, it
would lose its state.
It's the responsibility of a coroutine scheduler to take a snapshot() when
a task is
At 12:01 PM 10/18/2005 +0100, Gustavo J. A. M. Carneiro wrote:
def show_message(msg):
win = create_window(msg)
animate(win, xrange(10)) # slide down
yield Timeout(3)
animate(win, xrange(10, 0, -1)) # slide up
win.destroy()
This obviously doesn't work, because calling
At 11:59 PM 10/18/2005 +1000, Nick Coghlan wrote:
An idea that was kicked around on c.l.p a long while back was statement
local
variables, where you could define some extra names just for a single simple
statement:
x = property(get, set, delete, doc) given:
doc = Property x (must be
At 08:46 PM 10/17/2005 -0700, Guido van Rossum wrote:
Now, if I were to follow Paul Graham's recommendations strictly
(http://www.paulgraham.com/diff.html), point 7 saysthat Python should
have a symbol type. I've always maintained that this is unnecessary
and that we can just as well use regular
At 09:17 AM 10/15/2005 +0100, Michael Hudson wrote:
Phillip J. Eby [EMAIL PROTECTED] writes:
Indeed, even pystone doesn't do much attribute access on the first
argument
of most of its functions, especially not those in inner loops. Only
Proc1() and the Record.copy() method do anything
I ran across an interesting paper about some VM optimizations yesterday:
http://www.object-arts.com/Papers/TheInterpreterIsDead.PDF
One thing mentioned was that saving even one cycle in their 'PUSH_SELF'
opcode improved interpreter performance by 5%. I thought that was pretty
cool, and
At 02:41 PM 10/14/2005 -0400, Raymond Hettinger wrote:
YAGNI
If the feature were there, I'd have used it already, so I wouldn't consider
it YAGNI. In the cases where I would've used it, I instead split generated
code into separate functions so I could compile() each one with a different
At 12:33 AM 10/15/2005 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Anyway, my main question is, do these sound like worthwhile
optimizations?
In the past, I think the analysis was always no. It adds
an opcode, so increases the size of the switch, causing
more pressure on the cache
At 04:02 PM 10/13/2005 +0100, Michael Hudson wrote:
Greg Ewing [EMAIL PROTECTED] writes:
Phillip J. Eby wrote:
At 01:47 PM 10/13/2005 +1300, Greg Ewing wrote:
I'm trying to change the __class__ of a newly-imported
module to a subclass of types.ModuleType
It happened in Python 2.3
At 01:43 PM 10/14/2005 +1300, Greg Ewing wrote:
Jeremy Hylton wrote:
Some of the finer points of generating the line number table (lnotab)
are wrong. There is some very delicate code to support single
stepping with the debugger.
With disk and memory sizes being what they are nowadays,
is
At 02:25 PM 10/14/2005 +1300, Greg Ewing wrote:
Phillip J. Eby wrote:
+1. I'd be especially interested in lifting the current requirement
that line ranges and byte ranges both increase monotonically. Even
better if the lines for a particular piece of code don't have to all
come from
At 02:35 AM 10/12/2005 +, Joshua Spoerri wrote:
that stm paper isn't the end.
there's a java implementation which seems to be exactly what we want:
http://research.microsoft.com/~tharris/papers/2003-oopsla.pdf
There's already a Python implementation of what's described in the
paper. It's
At 01:33 PM 10/10/2005 +1300, Greg Ewing wrote:
Phillip J. Eby wrote:
Clearly, the cost of function calls in Python lies somewhere else, and I'd
probably look next at parameter tuple allocation,
For simple calls where there aren't any *args or other
such complications, it seems like
At 09:50 PM 10/7/2005 +1000, Nick Coghlan wrote:
Notice how a non-coroutine callable can be yielded, and it will still work
happily with the scheduler, because the desire to continue execution is
indicated by the ContinueIteration exception, rather than by the type of the
returned value.
Wh?
At 10:47 AM 10/7/2005 -0600, Bruce Eckel wrote:
Also, look at the work that Scott Meyers, Andrei Alexandrescu, et al
did on the Double Checked Locking idiom, showing that it was broken
under threading. That was by no means trivial and obvious during all
the years that people thought that it
At 12:15 PM 10/7/2005 -0700, Martin Maly wrote:
Based on the binding rules described in the Python documentation, I
would expect the code to throw because binding created on the line (1)
is local to the class block and all the other __doc__ uses should
reference that binding. Apparently, it is not
At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
Okay, basic principal first. You start with a sandboxed thread that
has access to nothing. No modules, no builtins, *nothing*. This
means it can run without the GIL but it can't do any work.
It sure can't. You need at least the threadstate and a
At 07:17 PM 10/7/2005 -0600, Adam Olsen wrote:
On 10/7/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
Turns out it's quite easy and it doesn't harm performance of existing
code or require modification (but a recompile is necessary). The idea
At 10:09 PM 10/5/2005 -0700, Neal Norwitz wrote:
I've also been thinking about avoiding tuple creation when calling
python functions. The change I have in mind would probably have to
wait until p3k, but could yield some speed ups.
Warning: half baked idea follows.
Yeah, I've been baking that
At 07:36 AM 10/6/2005 -0500, Matthew F. Barnes wrote:
I posted this question to python-help, but I think I have a better chance
of getting the answer here.
I'm looking for clarification on when NEWLINE tokens are generated during
lexical analysis of Python source code.
If you're talking about
At 07:34 PM 10/6/2005 -0700, Guido van Rossum wrote:
How does this sound to the non-AST-branch developers who have to
suffer the inevitable post-merge instability? I think it's now or
never -- waiting longer isn't going to make this thing easier (not
with several more language changes approved:
At 09:50 AM 10/4/2005 +0100, Michael Hudson wrote:
(anyone still thinking about removing the block stack?).
I'm not any more. My thought was that it would be good for performance, by
reducing the memory allocation overhead for frames enough to allow pymalloc
to be used instead of the platform
At 12:37 PM 10/3/2005 -0400, Jason Orendorff wrote:
I'm -1 on PEP 343. It seems ...complex. And even with all the
complexity, I *still* won't be able to type
with self.lock: ...
which I submit is perfectly reasonable, clean, and clear.
Which is why it's proposed to add __enter__/__exit__
At 07:02 PM 10/3/2005 +0100, Michael Hudson wrote:
Phillip J. Eby [EMAIL PROTECTED] writes:
Since the PEP is accepted and has patches for both its implementation
and a
good part of its documentation, a major change like this would certainly
need a better rationale.
Though given
At 05:15 PM 10/3/2005 -0400, Jason Orendorff wrote:
Phillip J. Eby writes:
You didn't offer any reasons why this would be useful and/or good.
It makes it dramatically easier to write Python classes that correctly
support 'with'. I don't see any simple way to do this under PEP 343;
the only
At 09:49 AM 9/29/2005 -0400, Viren Shah wrote:
[I sent this earlier without being a subscriber and it was sent to the
moderation queue so I'm resending it after subscribing]
Hi,
I'm running a 64-bit Fedora Core 3 with python 2.3.4. I'm trying to
install setuptools to use with Trac, and get
At 09:10 AM 9/28/2005 -0700, Micah Elliott wrote:
I agree that proof of value is necessary. Without a spec though it
will be hard to get people to know about a convention/toolset, so it's
a bit of a chicken-egg problem -- I can't have a pep until the tools are
in use, but the tools won't be used
At 09:30 AM 9/29/2005 -0600, Bruce Eckel wrote:
This paper looks very interesting and promises some good ideas. It
also looks like it will require time and effort to digest.
I've only read the first few pages, but one thing that does leap out
is at the beginning of section 3, they say:
... a
At 12:14 PM 9/29/2005 -0400, Viren Shah wrote:
File /root/svn-install-apps/setuptools-0.6a4/pkg_resources.py, line
949, in _get
return self.loader.get_data(path)
OverflowError: signed integer is greater than maximum
Interesting. That looks like it might be a bug in the Python zipimport
At 10:48 AM 9/29/2005 -0600, Bruce Eckel wrote:
I haven't spent the weekends on the paper yet (but it looks like that
is what it would take), but I had the impression that they were
talking about the lock-free techniques such as the ones used in Java
5. Basically, you start a write operation in
At 03:12 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
Hi,
a general question. Consider:
class A(list):
def __setitem__(self, index, item):
# do something with index and item
return list.__setitem__(self, index, item)
lst = A([1,set()])
lst[0] |= 1
lst[1] |= set([1])
At 10:16 AM 9/28/2005 -0400, Jim Fulton wrote:
I do this often enough that I think it would be useful to include it
in python, either as a builtin (like property) or in the library. (Or
possibly by adding an option to property to generate a read
descriptor.) I'd be happy to add this for 2.5.
At 05:15 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
Okay. I assume that we must accept that
s = set()
t = (s,)
t[0] |= set([1])
changes s in spite of raising TypeError.
There are lots of operations that can be partially completed before raising
an error, so I'm not sure why this case would
At 05:40 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
Rather than closing this as invalid, it would be wiser to update the
documentation before ! Nothing corresponds to the current behavior.
I got my information from here:
At 06:15 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
Regularly, you see questions about augmented assignment on Python-tutor
mailing list, I often have question in my lab because of problems ...
most of the time people learn to avoid these operators in the end ! And
my look in the
At 05:28 PM 9/28/2005 +, iga Seilnacht wrote:
You can use something like this to find a descriptor's name:
snip
The given code fails if the same property appears under more than one name
or is used in more than one class. It also requires the property object to
be mutable, and is
At 06:23 PM 9/28/2005 -0400, Barry Warsaw wrote:
I /must/ be missing something. Why not just use property as a
decorator?
class C:
@property
def eggs(self):
print 'in eggs'
self.eggs = 7
return self.eggs
c = C()
c.eggs
in eggs
7
c.eggs
7
Because it
At 11:18 AM 9/27/2005 -0600, Bruce Eckel wrote:
Yes, defining an class as active would:
1) Install a worker thread and concurrent queue in each object of that
class.
2) Automatically turn method calls into tasks and enqueue them
3) Prevent any other interaction other than enqueued messages
#3 is
At 03:35 PM 9/26/2005 -0700, Micah Elliott wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
at http://www.python.org/peps/pep-0350.html.
At 10:27 AM 9/22/2005 +0400, Sokolov Yura wrote:
It is so simple to write application server in Python.
It is so difficult to make it scallable in CPython.
It seems you've never heard of fork(), which works just fine to scale
Python processes on multiprocessor boxes. I've actually done this,
At 08:19 AM 9/22/2005 -0700, Rich Burridge wrote:
Hi,
Recently I asked about the inclusion of a vendor-packages
directory for Python on the Python mailing list.
See the thread started at:
http://mail.python.org/pipermail/python-list/2005-September/300029.html
for the full reasoning behind
At 12:04 PM 9/22/2005 -0700, Rich Burridge wrote:
Phillip J. Eby wrote:
Recently I asked about the inclusion of a vendor-packages
directory for Python on the Python mailing list.
See the thread started at:
http://mail.python.org/pipermail/python-list/2005-September/300029.html
for the full
At 08:42 PM 9/22/2005 +0200, Fredrik Lundh wrote:
Phillip J. Eby wrote:
At 10:27 AM 9/22/2005 +0400, Sokolov Yura wrote:
It is so simple to write application server in Python.
It is so difficult to make it scallable in CPython.
It seems you've never heard of fork(), which works just fine
At 01:18 PM 9/22/2005 -0700, Rich Burridge wrote:
Phillip J. Eby wrote:
Right - I'm proposing you add a vendor-packages.pth file to
site-pacakges, that points to a totally separate base directory where
those files are installed, not that you install the packages themselves
under site-packages
At 12:04 PM 9/21/2005 -0700, Guido van Rossum wrote:
Actually Python itself has a hard time keeping multiple interpreters
truly separate. Also of course there are some shared resources
maintained by the operating system: current directory, open file
descriptors, signal settings, child processes,
At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use colons.
+1, despite the fact that we seem on a slippery slope
At 06:10 PM 9/20/2005 -0400, Bob Ippolito wrote:
My use case for this isn't so much about threads, but plug-ins.
Writing multiple Python-based plug-ins for an application is always a
mess, because they share too much (sys.modules, sys.path, etc.).
PyObjC would benefit greatly from this feature,
At 12:32 PM 9/17/2005 -0400, Luis P Caamano wrote:
My point is that not yielding speedups on multiprocessors
and hurting performance on uniprocessors is not a good
or valid reason to drop free-threading.
It is if you have only volunteers to maintain the code base, and the
changes significantly
At 05:44 PM 9/15/2005 -0400, Raymond Hettinger wrote:
[Neal Norwitz]
That shows the magic number changing. You will need to read CVS logs
to figure out why. It's possible the numbers don't really *need* to
change.
The new LIST_APPEND opcode won't run on Py2.3.
The OP asked about
At 06:55 PM 9/14/2005 +0200, Martin v. Löwis wrote:
Neal Norwitz wrote:
This code doesn't really work in general. It assumes that any append
function call is a list method, which is obviously invalid. But if a
variable is known to be a list (ie, local and assigned as list
(BUILD_LIST) or
At 09:12 PM 9/14/2005 +0400, Sokolov Yura wrote:
We could cash looks by this way:
Store with a class its version. Every time after creation when we change
a class
(add,remove or chage class member, including __base__, __bases__ and mro) ,
we increase the version number. Lets call it VERSION
FYI,
At 09:58 PM 9/6/2005 -0700, Guido van Rossum wrote:
On 9/6/05, Greg Ewing [EMAIL PROTECTED] wrote:
A better plan would be to build something akin to
Pyrex into the scheme of things, so that all the
refcount/GC issues are taken care of automatically.
That sounds exciting. I have to admit
At 12:04 PM 9/5/2005 -0400, Edward C. Jones wrote:
Normally I can use any method of a class anywhere in the definition of
the class.
Not true. You can certainly use any method of a class in any *functions*
or methods defined in the body of the class. But you can't use them in the
body of the
At 06:24 PM 9/3/2005 +1000, Christopher Armstrong wrote:
For example, perhaps a better idea would be to
change the traceback-printing functions to use Python attribute lookup
instead of internal structure lookup, and then change raise to accept
arbitrary Python objects as its third argument, as
At 11:02 AM 9/3/2005 +1000, Nick Coghlan wrote:
Printing the items in a sequence also becomes straightforward:
print .join(map(str, range(10))) = output(*range(10))
Playing well with generator expressions comes for free, too:
print .join(str(x*x) for x in range(10))
= output(*(x*x for x
At 04:55 AM 8/31/2005 -0700, Michael Chermside wrote:
Raymond's original definition for partition() did NOT support any
of the following:
(*) Regular Expressions
This can be orthogonally added to the 're' module, and definitely should
not be part of the string method.
(*) Ways to
At 10:01 AM 8/30/2005 +0200, Fredrik Lundh wrote:
Phillip J. Eby wrote:
Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See:
http://www.jacquardsystems.com/Examples/function/piece.htm
As far as I can see, either you misunderstand what partition() does, or
I'm
completely
At 02:25 PM 8/30/2005 -0400, Raymond Hettinger wrote:
That case should be handled with consecutive partitions:
# keep everything after the second 'X'
head, found, s = s.partition('X')
head, found, s = s.partition('x')
Or:
s=s.partition('X')[2].partition('X')[2]
which actually suggests a
At 07:54 PM 8/30/2005 +0200, Fredrik Lundh wrote:
Phillip J. Eby wrote:
both split on a given token. partition splits once, and returns all three
parts, while piece returns the part you ask for
No, because looking at that URL, there is no piece that is the token split
on. partition
At 01:05 AM 8/31/2005 +0200, Fredrik Lundh wrote:
Ron Adam wrote:
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
At 02:10 PM 8/25/2005 -0500, Ian Bicking wrote:
I was trying to translate a pattern that uses closures in a language
like Scheme (where closed values can be written to) to generators using
PEP 342, but I'm not clear exactly how it works; the examples in the PEP
have different motivations. Since I
At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote:
then of course, one could change ``unicode.__str__()`` to return
``self``, itself, which should work. but then, why so complicated?
I think that may be the right fix.
No, it isn't. Right now str(ux) coerces the unicode object to a string,
At 10:54 AM 8/23/2005 -0600, Neil Schemenauer wrote:
On Tue, Aug 23, 2005 at 11:43:02AM -0400, Phillip J. Eby wrote:
At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote:
then of course, one could change ``unicode.__str__()`` to return
``self``, itself, which should work. but then, why so
At 07:23 PM 8/23/2005 +0200, Reinhold Birkenfeld wrote:
[EMAIL PROTECTED] wrote:
I'm not a native speaker, but...
@@ -114,7 +114,7 @@
programs, or to test functions during bottom-up program development.
It is also a handy desk calculator.
-Python allows writing very compact and
At 10:07 AM 8/8/2005 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Hm. What would be the use case for using %s with binary, non-text data?
Well, I could see using it to write things like netstrings,
i.e. sock.send(%d:%s, % (len(data),data)) seems like the One Obvious
Way
At 09:14 AM 8/8/2005 -0700, Guido van Rossum wrote:
I'm not going to change my mind on text() unless
someone explains what's so attractive about it.
1. It's obvious to non-programmers what it's for (str and unicode aren't)
2. It's more obvious to programmers that it's a *text* string rather than
At 09:12 PM 8/8/2005 -0400, Tim Peters wrote:
I can't think of a Python feature with a higher aggregate
braincell_burned / benefit ratio than __del__ methods. If P3K retains
them-- or maybe even before --we should consider taking the Java
dodge on this one. That is, decree that henceforth a
At 05:24 PM 8/7/2005 -0700, Guido van Rossum wrote:
Hm. What would be the use case for using %s with binary, non-text data?
Well, I could see using it to write things like netstrings,
i.e. sock.send(%d:%s, % (len(data),data)) seems like the One Obvious Way
to write a netstring in today's
At 02:46 PM 8/5/2005 -0400, Raymond Hettinger wrote:
The PEP moves StopIteration out from under Exception so that it cannot
be caught by a bare except or an explicit except Exception.
IMO, this is a mistake. In either form, a programmer is stating that
they want to catch and handle just about
At 10:53 AM 8/2/2005 -0400, James Y Knight wrote:
No... KeyboardInterrupt (just like other asynchronous exceptions)
really should be treated as a critical error. Doing anything other
than killing your process off after receiving it is just inviting
disaster. Because the exception can have occurred
At 05:05 PM 7/31/2005 +1000, Nick Coghlan wrote:
Brett Cannon wrote:
Notice that I've classified KeyboardInterrupt as user-initiated control
flow
and put it under ControlFlowException above. This means that everything
under
CriticalError and Error actually ends with the word 'Error'.
I
At 12:12 PM 7/31/2005 -0400, James Y Knight wrote:
On Jul 30, 2005, at 8:57 PM, Nick Coghlan wrote:
I wouldn't mind using Exception/Error instead of Raisable/Exception
- and it
seriously reduces the pain of making this transition. Indeed, most
of it
becomes doable within the 2.x series -
At 06:39 PM 7/29/2005 -0400, Barry Warsaw wrote:
But that would still require us to create accounts for every committer,
right?
No. Just one account. You can have more than one key listed in
authorized_keys, using svnserve --tunnel-user and sshd will select the
right command based on the
At 09:12 PM 7/6/2005 +1000, Nick Coghlan wrote:
Another example is the use of contexts to handle insertion of the
appropriate tags when generating HTML:
with html:
with body:
with h1:
print Some heading
with p:
print This is paragraph
At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
[Guido, on {for,while}/else]
...
The question remains whether Python would be easier to learn without
them. And if so, the question would remain whether that's offset by
their utility for experienced developers. All hard to assess
impartially!
At 11:48 PM 7/3/2005 -0400, Raymond Hettinger wrote:
Remember,
these methods are going to show up in objects such as Context which are
not primarily about 343. All of the other methods names will have
nothing to do with 343, so our choice of magic names needs to be really
good (as there will
At 03:04 PM 7/3/2005 +0100, Michael Hudson wrote:
Phillip J. Eby [EMAIL PROTECTED] writes:
At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation
At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote:
There may be cases where the object being managed is not a resource
per-se, but that doesn't mean that the mechanism is misnamed as a
'resource manager'; it's just the most common use case that any of
us
have managed to think of (as
At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
Resource managers.
___
Python-Dev mailing list
At 03:59 PM 7/1/2005 -0700, Ralf W. Grosse-Kunstleve wrote:
Hi,
I often find myself writing:
class grouping:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
I hate it, and every time I show this to a Python newcomer I get that
skeptic
At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
os.getcwd() returns a string, but path.getcwd() returns a new path
object.
In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a
constructor classmethod by analogy with 'dict.fromkeys()' or
'datetime.now()'. 'getcwd()'
At 05:10 PM 6/27/2005 +0200, Reinhold Birkenfeld wrote:
Phillip J. Eby wrote:
At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
os.getcwd() returns a string, but path.getcwd() returns a new path
object.
In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e
At 08:24 PM 6/27/2005 +0100, Michael Hoffman wrote:
On Mon, 27 Jun 2005, Phillip J. Eby wrote:
At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
os.getcwd() returns a string, but path.getcwd() returns a new path
object.
In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd
At 03:45 PM 6/27/2005 -0500, Skip Montanaro wrote:
We're getting enough discussion about various aspects of Jason's path module
that perhaps a PEP is warranted. All this discussion on python-dev is just
going to get lost.
AFAICT, the only unresolved issue outstanding is a compromise or
At 05:04 AM 6/26/2005 -0600, Adam Olsen wrote:
On 6/26/05, Ronald Oussoren [EMAIL PROTECTED] wrote:
Have a look at stackless python. http://www.stackless.com/
On 6/26/05, Florian Schulze [EMAIL PROTECTED] wrote:
Also look at greenlets, they are in the py lib http://codespeak.net/py
While
At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
1226256:
The path module by Jason Orendorff should be in the standard library.
http://www.jorendorff.com/articles/python/path/
Review: the module is great and seems to have a large user base. On c.l.py
there are frequent praises about it.
I
At 09:00 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
One more issue is open: the one of naming. As path is already the name of
a module, what would the new object be called to avoid confusion? pathobj?
objpath? Path?
I was thinking os.Path, myself.
At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote:
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
* drop getcwd(); it makes no sense on a path instance
Personally I use path.getcwd() as a class method all the time. It
makes as much sense as fromkeys() does on a dict instance, which is
technically
At 02:31 PM 6/26/2005 -0500, Skip Montanaro wrote:
Phillip It has many ways to do the same thing, and many of its property
Phillip and method names are confusing because they either do the same
Phillip thing as a standard function, but have a different name (like
Phillip the
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
[...]
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e. ctime/mtime/atime
and
size really shouldn't be properties, but rather methods.
I think ctime, mtime and atime
At 12:08 PM 6/27/2005 +1200, Tony Meyer wrote:
[Reinhold Birkenfeld]
One more issue is open: the one of naming. As path is already the
name of a module, what would the new object be called to avoid
confusion? pathobj? objpath? Path?
[Michael Hoffman]
I would argue for Path.
Granted path
At 08:29 PM 6/26/2005 -0500, Skip Montanaro wrote:
Phillip ... but have a different name (like the 'parent' property that
Phillip is os.path.dirname in disguise) ...
Phillip ... (like the 'listdir()' method that returns full paths rather
Phillip than just filenames).
At 09:26 PM 6/26/2005 -0400, Bob Ippolito wrote:
On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote:
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e. ctime/mtime
At 10:15 PM 6/18/2005 -0400, Phillip J. Eby wrote:
Okay, I think I see why you can't do it. You could guarantee that all
relevant __del__ methods get called, but it's bloody difficult to end up
with only unreachable items in gc.garbage afterwards. I think gc would
have to keep a new list
that allows an object to handle itself being garbage would be
handy, although it's only meaningful to have a __cleanup__ if you also have
a __del__; otherwise, there would never be a reason to call it. Maybe
that's the reason it was considered cumbersome.
At 04:16 PM 6/19/2005 -0400, Phillip J. Eby
At 04:55 PM 6/18/2005 +0300, Oren Tirosh wrote:
On 6/18/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote:
It turns out that making 'next(EXPR)' work is a bit tricky; I was going to
use METH_COEXIST and METH_VARARGS, but then it occurred to me
Working on the PEP 342/343 generator enhancements, I've got working
send/throw/close() methods, but am not sure how to deal with getting
__del__ to invoke close(). Naturally, I can add a __del__ entry to its
methods list easily enough, but the 'has_finalizer()' function in
gcmodule.c only
601 - 700 of 848 matches
Mail list logo
