t
from numerous people. Please feel free to give feedback and
raise questions.
contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html
have fun,
the pypy team, (Armin Rigo, Samuele Pedroni,
Holger Krekel, Christian Tismer,
Carl Friedrich Bolz, Michael Hudson,
James Y Knight <[EMAIL PROTECTED]> writes:
> On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
>
>> --- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>>> I think it is safe to say that Twisted is more widely used than
>>> anything
>>> Google has yet released. Twisted also has a reas
Benji York <[EMAIL PROTECTED]> writes:
> Nick Coghlan wrote:
>> Perhaps ImportWarning should default to being ignored, the same way
>> PendingDeprecationWarning does?
>>
>> Then -Wd would become 'the one obvious way' to debug import problems
>
> +1
I'm not sure what this would achieve -- people
"Brett Cannon" <[EMAIL PROTECTED]> writes:
> If you look at that crasher, you will notice that recursion depth is set
> to 1 << 30 before any code is run. If you remove that setting high
> setting and go with the default then the test doesn't crash and raises the
> appropriate RuntimeError.
>
> S
Ka-Ping Yee <[EMAIL PROTECTED]> writes:
> On Fri, 30 Jun 2006, Neal Norwitz wrote:
>> The current list of serious bugs are in the PEP:
>>
>> http://www.python.org/dev/peps/pep-0356/
>
> Among them is this one:
>
> Incorrect LOAD/STORE_GLOBAL generation
> http://python.org/sf/1501934
>
>
Michael Chermside <[EMAIL PROTECTED]> writes:
> Phillip Eby writes:
>> I don't see a problem with requiring '.x' to be used for both
>> reading and writing of outer-scope names; it just shouldn't be
>> required for an outer-scope name that you don't rebind in the
>> current scope.
>>
>>
Michael Hudson <[EMAIL PROTECTED]> writes:
> I'm not expecting anyone else to think hard about this on recent form,
> so I'll think about it for a bit and then fix it in the way that seems
> best after that. Feel free to surprise me.
And so that's what I did.
Gary Robinson <[EMAIL PROTECTED]> writes:
> That caused a bus error 100% of the time when I simply imported the
> module into Python and called getSumChiSquare(), i.e.:
>
import testfloat
testfloat.getSumChiSquare()
It doesn't for me (CVS HEAD, OS X Panther).
> Could it be that this i
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> I'm getting a compiler warning from your checkin:
"your"? Mine?
> C:\py25\Objects\floatobject.c(1430) : warning C4244: 'initializing' :
> conversion from 'double ' to 'float ', possible loss of data
That's this line:
float y = x;
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?
Hmm, don't know.
I talked about an object 'that conformed to the with protocol' at
EuroPython,
"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?
>
> Resource managers.
Thing is, there may b
On 3 Jul 2005, at 18:25, Josiah Carlson wrote:
> Just because not all cars are used as vehicles, does that mean that
> cars
> are not vehicles?
No, but it means calling all vehicles "cars" is dumb.
> There may be cases where the object being managed is not a resource
> per-se, but that doesn't
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> Another trouble with "resource managed" is that it makes little sense
> even when describing something that is clearly a resource (for instance,
> "locking objects are resource managed", what the heck could that mean,
> there is no hint about the p
On 4 Jul 2005, at 18:59, Raymond Hettinger wrote:
> P.S. I still don't follow the whole yours/mine comment from Michael.
> The offending code line was part of 2.136 which CVS says was checked-in
> by him on 5/27/2005 and then fixed by him on 6/30/2005.
Well, my confusion started and ended with t
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Gary Robinson wrote:
>> Are the docs wrong or am I misreading them? Or are you wrong?
>
> It turns out that I am wrong.
This is a long standing confusion. At one point, the documentation
said what you said, and it was just as wrong. There were eve
Barry Warsaw <[EMAIL PROTECTED]> writes:
> +1 on @contextmanager
>
> On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote:
>
>> > __enter__(self):
>> > __exit__(self, exc_type, exc_value, exc_traceback):
>>
>> These names should be changed to __beginwith__ and __endwith__.
-1.
> -0.
Florent Pillet <[EMAIL PROTECTED]> writes:
> I discovered an issue on Mac OS X that seems to relate to signal
> handling. I have a C binding in which I call the standard tmpfile()
> function. After calling it, I can't break Python anymore with CTRL-C.
> Investigating the Darwin source code for tm
Walter Dörwald <[EMAIL PROTECTED]> writes:
> Am 07.07.2005 um 20:00 schrieb Guido van Rossum:
>
+1 on @contextmanager
>>
>> +1.
>>
>> [__enter__, __exit__]
>>
> These names should be changed to __beginwith__ and __endwith__.
>
>>
>> -1. The PEP has had an extensive review period and
Walter Dörwald <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> Walter Dörwald <[EMAIL PROTECTED]> writes:
>> [...]
>>>I.e. will VAR still exist after the end of the block with its value
>>>the return value of __enter__() or will it revert
Ron Adam <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>
>> I even wonder if else-clauses on for/while were a good idea. (The one
>> on try is definitely a good idea since the use case is quite frequent
>> and only clumsily handled otherwise; the use cases for else on
>> for/while are less
Florent Pillet <[EMAIL PROTECTED]> writes:
> On 07/07/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>>>
>> > But with my threaded Python code, SIGINT doesn't work anymore after my
>> > binding has called tmpfile().
>>
>> Oh, threads.
&
Skip Montanaro <[EMAIL PROTECTED]> writes:
> Ummm... What's a "context manager"?
Something that goes
with ... as var:
^ here
If you have a better name, feel free to suggest it, but please catch
up on python-dev first (it's been discussed to unconsciousness, if not
quite death, in the las
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> However, you will find that with a), people will still pass --with-cxx,
> because they tend to "enable" all features they can find.
--with-fpectl, for example. Does anyone lurking here actually use
that, know what it does and require the functional
Tim Peters <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>> --with-fpectl, for example. Does anyone lurking here actually use
>> that, know what it does and require the functionality? Inquiring
>> minds want to know.
>
> I know what it intends to do:
Surpr
Tim Peters <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>>>> --with-fpectl, for example. Does anyone lurking here actually use
>>>> that, know what it does and require the functionality? Inquiring
>>>> minds want to know.
>
> [Tim, explains
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> This is exactly what I'm getting at: I can see the potential
> use for resource management (which is what started out the
> whole idea IIRC), but fail to see why you'd want to use it
> for anything more complicated than that.
I, as a concrete example,
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Ron Adam wrote:
>> 3. The "with" documentation could possibly be grouped with or after
>> the "try" documentation as it may be easier to understand in that context.
>
> I was looking for an appropriate place in the tutorial to put a couple of
> usa
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> - Subversion over SSH, using SSH key pairs. This would require
> to give committers accounts on the machine, which currently is
> ruled out by the administration policy of svn.python.org.
Would it work/how much risk would it be to create account
"George V. Neville-Neil" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm attempting to write a Packet class, and a few other classes for
> use in writing protocol conformance tests. For the most part this is
> going well except that I'd like to be able to pack and unpack byte
> strings with values that
Willem Broekema <[EMAIL PROTECTED]> writes:
> I realize it's major work to add recovery features to the CPython
> interpreter, so I don't think CPython will have anything like it soon
> and therefore also Python-the-language will not. Instead, my reason
> for mentioning this is to get the _concept
Donovan Baarda <[EMAIL PROTECTED]> writes:
> This is why I don't bother migrating any existing CVS projects to SVN;
> the benefits don't yet outweigh the pain of migrating.
I think they do. I was on dialup for a while, and would have _loved_
Python to be using SVN then -- and given how long diff
Guido van Rossum <[EMAIL PROTECTED]> writes:
> So here's a radical proposal (hear the scratching of the finglernail
> on the blackboard? :-).
>
> Start with Brett's latest proposal. Goal: keep bare "except:" but
> change it to catch only the part of the hierarchy rooted at
> StandardError.
>
> - C
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 8/6/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>> PEP 8 doesn't express any preference between the
>> two forms of raise statements:
>> raise ValueError, 'blah'
>> raise ValueError("blah")
>>
>> I like the second form better, because if the exce
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> Set the external encoding for stdin, stdout, stderr:
>
> (also an example for adding encoding support to an
> existing file object):
>
> def set_sys_std_encoding(encoding):
> # Load encoding supp
Barry Warsaw <[EMAIL PROTECTED]> writes:
> Unfortunately, I don't think "we" (meaning specifically the collective
> python.org admins) have much if any operational experience with
> Perforce.
Also (from someone who is on the fringes of the pydotorg admin set): I
don't know that much about subvers
Steven Bethard <[EMAIL PROTECTED]> writes:
> Raymond Hettinger wrote:
>> If the PEP can't resist the urge to create new intermediate groupings,
>> then start by grepping through tons of Python code to find-out which
>> exceptions are typically caught on the same line. That would be a
>> worthwhil
Anthony Baxter <[EMAIL PROTECTED]> writes:
> So I'm currently planning for a 2.4.2 sometime around mid September. I figure
> we cut a release candidate either on the 7th or 14th, and a final a week
> later.
Cool. I'm not sure how many outstanding bugs should be fixed before
2.4.2. Some stuff
Ronald Oussoren <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a
> checkout that is less than two hours old. I'm building a standard
> unix tree (no framework install):
It seems very likely that it was this change:
http://fisheye.cenqua.com
Wilfredo Sánchez Vega <[EMAIL PROTECTED]> writes:
>I'm curious about why Python lacks FileNotFoundError,
> PermissionError and the like as subclasses of IOError.
Good question. Lack of effort/inertia?
>Catching IOError and looking at errno to figure out what went
> wrong seems prett
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> It seems to me that auto testing of the tentatively updated trunk before
> final commitment would avoid the 'who checked in test-breaking code'
> messages that appear here occasionally.
I don't think there's any fundamental impossibility in setting
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Ronald Oussoren wrote:
>> I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a
>> checkout that is less than two hours old. I'm building a standard
>> unix tree (no framework install):
>
> I just committed what I think is a bugfix for t
[EMAIL PROTECTED] writes:
> You don't need something like a buggy SWIG to put non-strings in dir().
>
class C: pass
> ...
C.__dict__[3] = "bad wolf"
dir(C)
> [3, '__doc__', '__module__']
>
> This is likely to happen "legitimately", for instance in a class that allows
> x.y and x['y'
Tim Peters <[EMAIL PROTECTED]> writes:
> [Martin v. Löwis]
>> I have placed a new version of the PEP on
>>
>> http://www.python.org/peps/pep-0347.html
>
> ...
>
> +1 from me. But, I don't think my vote should count much, and (sorry)
> Guido's even less: what do the people who frequently check i
Barry Warsaw <[EMAIL PROTECTED]> writes:
> On Tue, 2005-08-16 at 07:42, Michael Hudson wrote:
>
>> The third set of people who count are pydotorg admins. I'm not really
>> one of those either at the moment. While SF's CVS setup has it's
>> problems
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> This patch should be reverted or fixed so that the Py2.5 build works
> again.
>
> It contains a disasterous search and replace error that prevents it from
> compiling. Hence, it couldn't have passed the test suite before being
> checked in.
It
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> Could someone please make an independent check to verify an issue with
> the 342 checkin. The test suite passes but when I run IDLE and open a
> new window (using Control-N), it crashes and burns.
>
> The problem does not occur just before the che
; from
>> > compiling. Hence, it couldn't have passed the test suite before
> being
>> > checked in.
>
> [Michael Hudson]
>> It works for me, on OS X. Passes the test suite, even. I presume
>> you're on Windows of some kind?
>
>
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Gareth McCaughan wrote:
>
>> It's valid C99, meaning "this is an unsigned long long".
>
> since when does Python require C99 compilers?
Well, it doesn't, but Raymond was suggesting the code was GCC
specific, or something.
Cheers,
mwh
--
Check out
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
>> > Hmm, that may not be a killer. I wonder if it is possible to treat
>> > BaseException as a constant (like we do with None) and teach the
>> > compiler to interpret it as catching anything that gets raised so
> that
>> > "except BaseException" w
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 8/24/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> I really hope string exceptions can be killed off before 3.0. They
>> should be fully deprecated in 2.5.
>
> But what about class exceptions that don't in
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> writes:
> Phillip J. Eby wrote:
>
>> +1 for partition().
>
> Looks like I'm getting seriously outvoted here ... Still, as I said I
> don't think the name is overly important until the idea has been
> accepted anyway. How long did we go with people in fa
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> partition() works for me. It's not perfect, but it'll do. The idea
>> works for me rather more; it even simplifies the
>>
>> if s.startswith(prefix):
>> t = s[len(prefix
"Kurt B. Kaiser" <[EMAIL PROTECTED]> writes:
> Patch / Bug Summary
> ___
>
> Patches : 903 open (+551) / 5222 closed (+2324) / 6125 total (+2875)
Err ... ?
Cheers,
mwh
--
LaTeX, pah. Don't be silly. I'm using a homebrew markup system
that I wrote in Common Lisp. ;-)
Christopher Armstrong <[EMAIL PROTECTED]> writes:
> I had the idea to create a fake Traceback object in Python that
> doesn't hold references to any frame objects, but is still able to be
> passed to 'raise' and formatted as tracebacks are, etc. Unfortunately,
> raise does a type check on its thir
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 9/3/05, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> So here's the summary of the arguments against: two style points
>> (trailing comma and >>stream) (from the man who approved the current
>> decorator syntax!), and it's hard to extend. (By the way
Greg Ewing <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>
>>>While we're on the subject of Python 3000, what's the
>>>chance that reference counting when calling C
>>>functions from Python will go away?
>>
>> We'd have to completely change the implementation. We're not
>> planning on tha
"Andrew Koenig" <[EMAIL PROTECTED]> writes:
>> The only practical reason to like this feature is sparing the need of
>> finding an otherwise useless name for the formal argument. Another
>> reason, but not practical at all, is that the concept conveys some
>> elegance and originality (each progra
Martin Blais <[EMAIL PROTECTED]> writes:
> On 9/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 9/17/05, John J Lee <[EMAIL PROTECTED]> wrote:
>> > c. Since time is needed to iron out bugs (and perhaps also to reimplememt
>> >some pieces of code "from scratch"), very early in the life
Florian Weimer <[EMAIL PROTECTED]> writes:
> By the way, has anybody ever tried to create a CPython variant which
> uses a (mostly) copying garbage collector (or something else except
> reference counting or Boehm GC)?
Not to my knowledge. I've always thought that it would be pretty
hard. I'd b
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 9/19/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> I propose that in Py3.0, the "and" and "or" operators be simplified to
>> always return a Boolean value instead of returning the last evaluated
>> argument.
>
> While you're at it, maybe we s
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> I propose that in Py3.0, the "and" and "or" operators be simplified to
> always return a Boolean value instead of returning the last evaluated
> argument.
-1
> 2) When going back and forth between languages, it is easy to forget
> that only Pytho
Guido van Rossum <[EMAIL PROTECTED]> writes:
> Unfortunately, if we were to accept Raymond's proposal, we'd have to
> revisit the discussion, since his proposal removes several ways we
> currently avoid the need.
>
> In fact, I think Raymond's example is more properly considered an
> argument for
Brett Cannon <[EMAIL PROTECTED]> writes:
> On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> [SNIP]
>> I _like_ the explanation of 'and' and 'or' as they are now. They are
>> basically control flow constructs -- and have to be to get
>&
Guido van Rossum <[EMAIL PROTECTED]> writes:
>> Given the later addition of generator expressions with mandatory
>> parentheses , the mandatory-parentheses version of a conditional expression
>> looks less strange to me than it did then ;-). So I could happily use it
>> even though I may still le
BJörn Lindqvist <[EMAIL PROTECTED]> writes:
>> My problem with this syntax is that it can be hard to read:
>>
>> return if self.arg is None then default else self.arg
>>
>> looks worryingly like
>>
>> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
>
> That can already be written in Pytho
Reinhold Birkenfeld <[EMAIL PROTECTED]> writes:
> Anthony Baxter wrote:
>> Starting in about 11 hours time, the release24-maint branch is FROZEN
>> for the 2.4.2c1 release. The freeze will last for around a day, and
>> then we're in a state of mostly-frozen for another week, until 2.4.2
>> (fin
Anthony Baxter <[EMAIL PROTECTED]> writes:
> On Thursday 22 September 2005 23:36, Jeremy Maxfield wrote:
>> Can the fix for [ 1163563 ] Sub threads execute in restricted mode
>> (
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&gr
>>oup_id=5470&atid=105470 )
>> go in before 2.4
Jeremy Maxfield <[EMAIL PROTECTED]> writes:
> Sorry I think you're 'much mistaken'...
>
> The revision of PyState.c in the rc242c1 looks like 2.38.22 (should be
> 2.42)
> and threadmodule.c looks like 2.59 (should be 2.64)
Looks like you're right but SF CVS is being *astonishingly* slow right
Michael Hudson <[EMAIL PROTECTED]> writes:
> Jeremy Maxfield <[EMAIL PROTECTED]> writes:
>
>> Sorry I think you're 'much mistaken'...
>>
>> The revision of PyState.c in the rc242c1 looks like 2.38.22 (should be
>> 2.42)
>> and
"Gregory P. Smith" <[EMAIL PROTECTED]> writes:
> On Mon, Sep 19, 2005 at 09:12:05PM +0100, Michael Hudson wrote:
>> Martin Blais <[EMAIL PROTECTED]> writes:
>> > http://www.gotw.ca/publications/concurrency-ddj.htm
>> > The Free Lunch Is Over:
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> Unfortunately, finding out a descriptor's name is non-trivial; it'd be nice
> if there were a descriptor hook __bind__(cls,name) that was called by
> classes during cls.__new__ or assignment to a class attribute, and which
> you could define to ret
Bruce Eckel <[EMAIL PROTECTED]> writes:
> I'd like to restart this discussion; I didn't mean to put forth active
> objects as "the" solution, only that it seems to be one of the better,
> more OO solutions that I've seen so far.
>
> What I'd really like to figure out is the "pythonic" solution for
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> 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
Reinhold Birkenfeld <[EMAIL PROTECTED]> writes:
> Hi,
>
> I looked whether I could make the test suite pass again
> when compiled with --disable-unicode.
>
> One problem is that no Unicode escapes can be used since compiling
> the file raises ValueErrors for them. Such strings would have to
> be p
Travis Oliphant <[EMAIL PROTECTED]> writes:
> Thanks for the tip. I think I figured out the problem, and it was my
> misunderstanding of how types inherit in C that was the source of my
> problem.
>
> Basically, Python is doing what you would expect, the mp_item is used
> for __getitem__ if
Martin Blais <[EMAIL PROTECTED]> writes:
> What if we could completely disable the implicit conversions between
> unicode and str? In other words, if you would ALWAYS be forced to
> call either .encode() or .decode() to convert between one and the
> other... wouldn't that help a lot deal with tha
"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 the amount of interest said patch has attracted (none at
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> 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
Neal Norwitz <[EMAIL PROTECTED]> writes:
> On 10/5/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> 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 though
"Matthew F. Barnes" <[EMAIL PROTECTED]> writes:
> 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. In particular, I'm conf
Guido van Rossum <[EMAIL PROTECTED]> writes:
> 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: wi
Nick Coghlan <[EMAIL PROTECTED]> writes:
> What if we simply special-cased the __with__ slot in type(), such that if it
> is populated with a generator object, that object is automatically wrapped
> using the @contextmanager decorator? (Jason actually suggested this idea
> previously)
You don
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
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> Even better if the lines for a particular piece of code don't have
> to all come from the same file.
This seems _fairly_ esoteric to me. Why do you need it?
I can think of two uses for lnotab information: printing source lines
and locating source l
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 09:23 AM 10/14/2005 +0100, Michael Hudson wrote:
>>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>>
>> > Even better if the lines for a particular piece of code don't have
>> > t
"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 that would be helped by
> SELF_ATTR. But it seems
> Maybe, but the issues on the table are naming issues -- is __with__
> the right name, or should it be __context__? Should the decorator be
> applied implicitly? Should the decorator be called @context or
> @contextmanager?
>
>> In the months
>> since the discussion and app
Tim Peters <[EMAIL PROTECTED]> writes:
> Turns out it's _not_ input speed that's the problem here, and not even
> mainly the speed of integer mod: the bulk of the time is spent in
> int(string) (and, yes, that's also far more important to the problem
> Neal was looking at than list.append time).
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> I'd like to start the subversion switchover this coming Wednesday,
> with a total commit freeze at 16:00 GMT.
Yay! Thanks again for doing this.
Cheers,
mwh
--
[Perl] combines all the worst aspects of C and Lisp: a billion
different sublangua
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Josiah Carlson wrote:
>> You can get the same semantics with...
>>
>> class NAME(_(TYPE), ARGS):
>> BLOCK
>>
>> And a suitably defined _. Remember, not every X line function should be
>> made a builtin or syntax.
>
> And this would be an extremely
[EMAIL PROTECTED] writes:
> The Python source code repository is now converted to subversion;
> please feel free to start checking out new sandboxes. For a few
> days, this installation probably still needs to be considered in
> testing. If there are no serious problems found by next Monday,
> I w
Thomas Heller <[EMAIL PROTECTED]> writes:
> Can anyone recommend an XEmacs svn plugin to use - I've tried psvn.el
> from http://www.xsteve.at/prg/emacs/psvn.el which seems to work?
I've heard http://www.xsteve.at/prg/emacs/psvn.el works :)
I also have vc-svn.el installed (I think it's from the s
nts: http://codespeak.net/pypy/dist/pypy/doc/contact.html
have fun,
the pypy team, (Armin Rigo, Samuele Pedroni,
Holger Krekel, Christian Tismer,
Carl Friedrich Bolz, Michael Hudson,
and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html)
PyPy developme
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> BJörn Lindqvist wrote:
>> How would the value equality operator deal with recursive objects?
>>
>> class Foo:
>> def __init__(self):
>> self.foo = self
>>
>> Seems to me that it would take atleast some special-casing to get
>> Foo() ==
Greg Ewing <[EMAIL PROTECTED]> writes:
> James Y Knight wrote:
>
>> ITYM you mean "If only python were lisp". (macros, or even reader macros)
>
> No, I mean it would be more satisfying if there
> were a syntax for expressing multiline string
> literals that didn't force it to be at the left
> mar
Gothenburg PyPy Sprint II: 7th - 11th December 2005
==
(NOTE: internal EU-only sprint starts on the 5th!)
The next PyPy sprint is scheduled to be in December 2005 in Gothenborg,
Sweden. Its main focus is heading towards phase 2, which means JIT
Travis Oliphant <[EMAIL PROTECTED]> writes:
> Bingo. Yes, definitely allocating new _types_ (an awful lot of them...)
> --- that's what the "array scalars" are: new types created in C.
Ah! And, er, why?
> If they don't get properly collected then that would definitely have
> created the probl
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Armin Rigo wrote:
>> If anyone feels like this is a bad idea, please speak up.
>
> As stated, it certainly is a bad idea.
This is a bit extreme...
> To make it a good idea, there should also be some commitment to
> maintain this library for a numbe
Neal Norwitz <[EMAIL PROTECTED]> writes:
> There are still a few reference leaks I've been able to identify. I
> didn't see an obvious solution to these (well, I saw one obvious
> solution which crashed, so obviously I was wrong).
>
> When running regrtest with -R here are the ref leaks reported:
201 - 300 of 332 matches
Mail list logo
