[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/)
_
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
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
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
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
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"
> 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
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"
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
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
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
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
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
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
[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 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 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: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
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
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
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
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
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
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
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
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
> 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, 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
> >
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
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.
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
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
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
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
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
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
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
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
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
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_
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) = *
[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
[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
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
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
45 matches
Mail list logo
