Ron Adam wrote:
I wonder if you make '*' work outside of functions arguments lists, if
requests to do the same for '**' would follow?
Only if keyword unpacking were to be permitted elsewhere first. That is:
Py data = dict(a=1, b=2, c=3)
Py (a, b, c) = **data
Py print a, b, c
(1, 2, 3)
Cheers,
Michael Chermside wrote:
Guido writes:
I've always wanted to write that as
f(a, b, *args, foo=1, bar=2, **kwds)
but the current grammar doesn't allow it.
Hmm why doesn't the current grammar allow it, and can we fix that?
I don't see that it's a limitation of the
[EMAIL PROTECTED] wrote:
Guido At some level, Queue is just an application of threading, while
Guido the threading module provides the basic API ...
While Queue is built on top of threading Lock and Condition objects, it is a
highly useful synchronization mechanism in its own right,
[EMAIL PROTECTED] wrote:
It sounds like he feels Queue should just be part of threading but queues
can be used in other contexts besides threading. So having separate
modules is a good thing.
If threads aren't involved, you should use collections.deque directly,
rather than going through
Nick Coghlan wrote:
Ron Adam wrote:
I wonder if you make '*' work outside of functions arguments lists, if
requests to do the same for '**' would follow?
Only if keyword unpacking were to be permitted elsewhere first. That is:
Py data = dict(a=1, b=2, c=3)
Py (a, b, c) = **data
Py
Greg Ewing wrote:
BTW, I agree that special *syntax* isn't necessarily
needed. But it does seem to me that some sort of
hook is needed somewhere to make this doable
smoothly, that doesn't exist today.
Having module attribute access obey the descriptor protocol (__get__, __set__,
__delete__)
I'd just like to point out that Queue is not quite as useful as people
seem to think in this thread. The main problem is that I can't
integrate Queue into a select/poll based main loop.
The other day I wanted extended a python main loop, which uses poll(),
to be thread safe, so I could queue
Bruce Eckel [EMAIL PROTECTED] writes:
Not only are there significant new library components in
java.util.concurrent in J2SE5, but perhaps more important is the new
memory model that deals with issues that are (especially) revealed in
multiprocessor environments. The new memory model
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, actually.
Is there a discussion anywhere about the
Greg All right then, how about putting it in a module called
Greg threadutils or something like that, which is clearly related to
Greg threading, but is open for the addition of future thread-related
Greg features that might arise.
Then Lock, RLock, Semaphore, etc belong there
Nick So the thread-related API would actually have three layers:
Nick- _thread (currently _thread) for the low-level guts
Nick- threading for the basic thread API that any threaded app needs
Nick- threadtools for the more complex application-specific items
Nick
On Thu, Oct 13, 2005, [EMAIL PROTECTED] wrote:
Given your list of stuff to go in a threadtools module, I still think
you need something to hold Lock, RLock, Condition and Semaphore. See
my previous post (subject: Threading and synchronization primitives)
about a threadutils module to hold
I don't know of anything that exists. There is an upcoming book that
may help:
Java Concurrency in Practice, by Brian Goetz, Tim Peierls, Joshua
Bloch, Joseph Bowbeer, David Holmes, and Doug Lea (Addison-Wesley
2006).
I have had assistance from some of the authors, but don't know if it
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,
Why not lazily import modules by importing them when they are needed
(i.e inside functions), and not in the top-level module scope?
On 10/13/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:02 PM 10/13/2005 +0100, Michael Hudson wrote:
Greg Ewing [EMAIL PROTECTED] writes:
Phillip J. Eby
Eyal Lotem [EMAIL PROTECTED] wrote:
Why not lazily import modules by importing them when they are needed
(i.e inside functions), and not in the top-level module scope?
Because then it wouldn't be automatic.
The earlier portion of this discussion came from...
import module
#module.foo
Guido van Rossum wrote:
BTW, Queue.Queue violates a recent module naming standard; it is now
considered bad style to name the class and the module the same.
Modules and packages should have short all-lowercase names, classes
should be CapWords. Even the same but different case is bad style.
On 10/13/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
BTW, Queue.Queue violates a recent module naming standard; it is now
considered bad style to name the class and the module the same.
Modules and packages should have short all-lowercase names, classes
should be
unfortunately, this standard seem to result in generic spamtools modules
into which people throw everything that's even remotely related to spam,
followed by complaints about bloat and performance from users, followed by
various more or less stupid attempts to implement lazy loading of hidden
On 10/13/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Greg All right then, how about putting it in a module called
Greg threadutils or something like that, which is clearly related to
Greg threading, but is open for the addition of future thread-related
Greg features that
Neil and I have been working on the AST branch for the last week.
We're nearly ready to merge the changes to the head. I imagine we'll
do it this weekend, barring last minute glitches.
There are a few open issues that remain. I'd like to merge the branch
before resolving them. Please let me
I'm excited to see work continuing (resuming?) on the AST tree.
I don't know how many machines you've been able to test the AST branch on. I
have a linux/amd64 machine handy and I've tried to run the test suite with a
fresh copy of the ast-branch.
test_trace segfaults consistently, even when
On Thu, Oct 13, 2005 at 05:08:41PM -0500, [EMAIL PROTECTED] wrote:
test_trace segfaults consistently, even when run alone.
That's a bug in frame_setlineno(), IMO. It's failing to detect an
invalid jump because the lnotab generated by the new compiler is
slightly different (DUP_TOP opcode
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 it still worth making heroic efforts to compress
Josiah Carlson wrote:
The earlier portion of this discussion came from...
import module
#module.foo does not reference a module
module.foo
#now module.foo references a module
Or more generally, module.foo now references *something*,
not necessarily a module. (In my use
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
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 the same file.
How about an array of:
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 the
Eyal Lotem wrote:
locals()['x'] = 1 # Quietly fails!
Replaced by:
frame.x = 1 # Raises error
Or even better, replaced by
frame.x = 1 # Does the right thing
The frame object knows enough to be able to find
the correct locals slot and update it, so there's
no need for this to
Agree.
i=1
def a():
i=2
def b():
print i
return b
a()()
2
def a():
i=2
def b():
exec print i
return b
a()()
1
___
Python-Dev mailing list
Python-Dev@python.org
Offtopic:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
G:\Working\1c:\Python24\python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
from os import fork
Traceback
And why not
if len(sys.argv) 1 take sys.argv[1] == 'debug':
...
It was not so bad :-)
A = len(sys.argv)==0 take None or sys.argv[1]
Sorry for being noisy :-)
___
Python-Dev mailing list
Python-Dev@python.org
May be allow modules to define __getattr__ ?
def __getattr__(thing):
try:
return __some_standart_way__(thing)
except AttributeError:
if thing==Queue:
import sys
from Queue import Queue
Sokolov Yura [EMAIL PROTECTED] wrote:
Offtopic:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
G:\Working\1c:\Python24\python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for
On Fri, Oct 14, 2005 at 01:03:28AM -0400, Raymond Hettinger wrote:
Do the AST branch generate a syntax error for:
foo(a = i for i in range(10))
No. It generates the same broken code as the current compiler.
Neil
___
Python-Dev mailing list
Technical Support of Intercable Co [EMAIL PROTECTED] wrote:
And why not
if len(sys.argv) 1 take sys.argv[1] == 'debug':
...
It was not so bad :-)
A = len(sys.argv)==0 take None or sys.argv[1]
Sorry for being noisy :-)
The syntax for 2.5 has already been decided upon. Except
Guido van Rossum wrote:
BTW, Queue.Queue violates a recent module naming standard; it is now
considered bad style to name the class and the module the same.
Modules and packages should have short all-lowercase names, classes
should be CapWords. Even the same but different case is bad
37 matches
Mail list logo
