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)
Che
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 o
[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 r
[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) = *
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 repr
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 anywhe
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
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 ho
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
introduces
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
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:
> >
> > > Phil
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.
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
> >
> 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
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> featur
On 10/13/05, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote:
> 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.
Well, you're mixing two incompatible
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 kn
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 run
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 corres
Phillip J. Eby wrote:
> Actually, it's desirable to be *able* to do it for anything. But certainly
> for otherwise-immutable objects it can lead to aliasing issues.
Even for immutables, it could be useful to be able to
add behaviour that doesn't mutate anything.
--
Greg Ewing, Computer Scienc
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 us
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 nowa
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 01:32 PM 10/14/2005 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > Actually, it's desirable to be *able* to do it for anything. But
> certainly
> > for otherwise-immutable objects it can lead to aliasing issues.
>
>Even for immutables, it could be useful to be able to
>add behaviour tha
[Phillip J. Eby]
> It'd be nice to be able to do the equivalent of '#line' directives for
> Python code that's generated by other tools, such as parser generators
> and the like.
I had such a need a few times in the past, and it was tedious having to
do indirections through generated Python for f
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
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 t
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
http://mail.python.org
Offtopic:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
G:\Working\1>c:\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
Tr
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
http://mail.python.org/mailman/listi
I have written my fastcharmap decoder and encoder. It's not meant to be
better than the patch and other changes to come in a future version of
Python, but it does work now with the current codecs. Using Hye-Shik
Chang's benchmark, decoding is about 4.3x faster than the base, and
encoding is about
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
setattr(sys.modules[__name__],"Queue"
> 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.
Nice work.
> I don't think the current test suite covers all of the possible syntax
> errors that can be raised.
Do the AST branch generate a syntax error for:
foo(a
Sokolov Yura <[EMAIL PROTECTED]> wrote:
>
> Offtopic:
>
> Microsoft Windows [Version 5.2.3790]
> (C) Copyright 1985-2003 Microsoft Corp.
>
> G:\Working\1>c:\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"
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 upo
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 c
On 10/11/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> locals()['x'] = 1 # Quietly fails!
> Replaced by:
> frame.x = 1 # Raises error
What about the possibility of making this hypothetic frame object an
indexable, such that frame[0] is the current scope, frame[1] is the
calling scope, et
[Jeremy]
> > 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.
[Raymond]
> Nice work.
Indeed. I should've threatened to kill the AST branch long ago! :)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
45 matches
Mail list logo
