Giovanni Bajo wrote:
a = []
for i in range(10):
>
> ... a.append(lambda: i)
> ...
>
print [x() for x in a]
>
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces people to
> use the "i=i" trick.
This has *nothing* to do with
Josiah Carlson wrote:
> What I asked before, and what I'd like to ask again, is if there are any
> _nontrivial uses_ of lexically nested scopes which are made cumbersome
> by our inability to write to parent scopes.
The trouble with taking that position is that the very
cases which would benefit
Tim Peters wrote:
> Note that this is quite unlike Scheme, in which declaration must
> appear before use (ignoring fancy letrec cases),
I think that's overstating things a bit -- mutually
recursive functions are quite easy to write in Scheme
and don't look at all "fancy" (unless you object for
so
Andrew Koenig wrote:
> Incidentally, I think that lexical scoping would also deal with the problem
> that people often encounter in which they have to write things like "lambda
> x=x:" where one would think "lambda x:" would suffice.
This is another red herring. Python's problem here
is not becau
Maybe do a make distclean. There was a problem where old versions of
zlib (those without inflateCopy) weren't supported. They are now, but
it's a configure check. That coupled with the upgrade and the 10.3 in
the pathname, seems like it's just something didn't get cleaned up
properly. You could
Ka-Ping Yee wrote:
> while offering a way to get proper
> lexical scopes for those who want to use them.
I don't disagree with anything you said, but I think it
would be a good idea to avoid using phrases like "proper
lexical scopes", which is likely to set people off on
a tangent. The issue isn
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [Giovanni Bajo]
>> Yes but:
>>
> a = []
> for i in range(10):
>> ... a.append(lambda: i)
>> ...
> print [x() for x in a]
>> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>. Do you agree that it would be ideal if the
Brett Cannon wrote:
> 1) Is removing 'file' from the builtins dict in PyInterpreterState (and
> maybe some other things) going to be safe enough to sufficiently hide
> 'file' confidently (short of someone being stupid in their C extension
> module and exposing 'file' directly)?
>
> 2) Changing
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yes but:
>
a = []
for i in range(10):
> ... a.append(lambda: i)
> ...
print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces
>
Mark Hammond wrote:
> that helps "mozilla the platform" more than it helps "firebox the browser"
^^^
Firebox - the sandfoxed web browser!
--
Greg
___
Python-Dev mailing list
Python-Dev@python
Just upgraded my Mac to OSX 10.4.7 yesterday. svn up'd Python trunk, then
"make clean ; configure ; make" and I see that building the zlib module
fails:
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I/Users/skip/src/
It's up to the release manager now to decide whether the pitchforks at
Google or the pitchforks in the larger Python community are sharper.
;-)
--Guido (ducks)
On 6/30/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 6/30/06, Jean-Paul Calderone <[EMAIL PROTECTED]> w
[Giovanni Bajo]
> Yes but:
>
a = []
for i in range(10):
> ... a.append(lambda: i)
> ...
print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces people to
> use the "i=i" trick.
[Tim Peters]
> So stay away fr
> >>> a = []
> >>> for i in range(10):
> ... a.append(lambda: i)
> ...
> >>> print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
Isn't this exactly what you'd expect? Maybe I've been writing Python
for too long... :-).
Bill
___
Python-Dev maili
> With "var":
>
> var a = 3
> def f():
> var b = 4
> def g():
> var c = 5
> a, b, c = 0, 1, 2 # changes outer a, outer b, and c
> g()
> f()
>
> Now i think this is a little bit weird, because the statement
> "var b = 4" in an outer scope
[Giovanni Bajo]
> Yes but:
>
> >>> a = []
> >>> for i in range(10):
> ... a.append(lambda: i)
> ...
> >>> print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces people to
> use the "i=i" trick.
So stay away from excruciat
Tim Peters <[EMAIL PROTECTED]> wrote:
>> ...
>> Incidentally, I think that lexical scoping would also deal with the
>> problem
>> that people often encounter in which they have to write things like
>> "lambda
>> x=x:" where one would think "lambda x:" would suffice.
>
> They _shouldn't_ encounter
[Andrew Koenig]
> Almost. What I really want is for it to be possible to determine the
> binding of every name by inspecting the source text of the program. Right
> now, it is often possible to do so, but sometimes it isn't.
Local names are always determined at compile-time in Python. What you
On Fri, 30 Jun 2006, Andrew Koenig wrote:
> The fundamental principle is that the binding of every name is determined
> during compilation, not during execution. This property does not quite
> apply to Python at present.
I think this property does apply. In your example:
> def g():
>
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
[snip lexical scoping option]
> Now i think this is a little bit weird, because the statement
> "var b = 4" in an outer scope changes the meaning of "b" in an
> inner scope. But it does have the virtue of retaining behaviour
> compatible with today's Python,
On 6/30/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > I read "a la Scheme" here as "actually nothing like Scheme, except I
> > want a non-tricky way to rebind a name from an enclosing scope within
> > an enclosed scope".
>
> Almost. What I really want is for it to be possible to determine the
>
[Andrew Koenig]
> ...
> Incidentally, I think that lexical scoping would also deal with the problem
> that people often encounter in which they have to write things like "lambda
> x=x:" where one would think "lambda x:" would suffice.
They _shouldn't_ encounter that at all anymore. For example,
At 07:04 PM 6/30/2006 -0400, Andrew Koenig wrote:
>However, if I write
>
> def g():
> return x
> x = 42
> g()
>
>the result is 42. With lexical scoping, I believe it should be undefined.
>
>The reason is that when the compiler encounters the definition of g,
> I read "a la Scheme" here as "actually nothing like Scheme, except I
> want a non-tricky way to rebind a name from an enclosing scope within
> an enclosed scope".
Almost. What I really want is for it to be possible to determine the
binding of every name by inspecting the source text of the prog
> That sounds like a bug, not a feature. It's frequently useful to have
> forward references in function bodies to names that are not yet globally
> bound, e.g. for classes, or mutually-recursive functions.
The trouble is that you don't necessarily know in what scope they will be
defined, so I t
[Andrew Koenig]
>>> I saw messages out of sequence and did not realize that this would be a
>>> change in behavior from 2.4. Sigh.
[Ka-Ping Yee]
>> Yes, this is not a good time to change it.
>>> I hope Py3000 has lexical scoping a la Scheme...
>> Me too -- that would be really nice.
[Guido]
>
Guido van Rossum wrote:
> On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>> On Fri, 30 Jun 2006, Andrew Koenig wrote:
>>> I hope Py3000 has lexical scoping a la Scheme...
>> Me too -- that would be really nice.
>
> That's not a very constructive proposal (especially since I don't know
> Scheme
> That's not a very constructive proposal (especially since I don't know
> Scheme). Perhaps you could elaborate on what needs to change?
The fundamental principle is that the binding of every name is determined
during compilation, not during execution. This property does not quite
apply to Python
On Fri, 30 Jun 2006, Guido van Rossum wrote:
> On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > On Fri, 30 Jun 2006, Andrew Koenig wrote:
> > > I hope Py3000 has lexical scoping a la Scheme...
> >
> > Me too -- that would be really nice.
>
> That's not a very constructive proposal (especially
On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
On Fri, 30 Jun 2006, Brett Cannon wrote:> On 6/30/06, Armin Rigo <[EMAIL PROTECTED]> wrote:> > >>> object.__subclasses__()> > [..., ]
> >> > Maybe this one won't work if __subclasses__ is forbidden, but in general> > I think there *will* be
On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Fri, 30 Jun 2006, Andrew Koenig wrote:
> > I saw messages out of sequence and did not realize that this would be a
> > change in behavior from 2.4. Sigh.
>
> Yes, this is not a good time to change it.
>
> > I hope Py3000 has lexical scoping a
python.org/sf/1515343 fixes python.org/sf/1515163, which is a
new-in-2.5 regression.
On the one hand, the regression only affects
>>> raise "string1", "string2"
which is both obscure and deprecated. On the other hand, it is a
regression, and it is something I bumped into while working with
unit
On Fri, 30 Jun 2006, Brett Cannon wrote:
> On 6/30/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> > >>> object.__subclasses__()
> > [..., ]
> >
> > Maybe this one won't work if __subclasses__ is forbidden, but in general
> > I think there *will* be a way to find this object.
>
> Yeah, that's b
On Fri, 30 Jun 2006, Andrew Koenig wrote:
> I saw messages out of sequence and did not realize that this would be a
> change in behavior from 2.4. Sigh.
Yes, this is not a good time to change it.
> I hope Py3000 has lexical scoping a la Scheme...
Me too -- that would be really nice.
-- ?!ng
_
On 6/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> The question is how long do we wait for the expat developers to patch> and do a micro release? Do we just leave this possible crasher in and> just rely entirely on the expat developers, or do we patch our copy and
> use
Tim Peters wrote:
> Don't know what "raw data" might mean here. Any Python object can be
> bound to any attribute of a class. In Python, e.g.,
>
> class MyClass:
>
> mydata = ['xyz', 12]
>
> def method(self):
> MyClass.mydata.append(-1)
> # or, more inheritance-frie
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Any pointers as to why there is a difference would be appreciated.
>
> This was fixed in r35540, r35541, r35542, r35543, by Nick Bastin
> and Armin Rigo, in response to #765624. Enough pointers :-?
Yes, thank you Martin
[Tim Peters]
>> I hope you've read PEP 307:
[Bruce Christensen]
> I have. Thanks to you and Guido for writing it! It's been a huge help.
You're welcome -- although we were paid for that, so thanks aren't needed ;-)
>> The implementation is more like:
>> [snip]
> Thanks! That helps a lot. PEP 30
[EMAIL PROTECTED] wrote:
> Noam Raphael posted an empty subscript PEP on the Python Wiki:
>
> http://wiki.python.org/moin/EmptySubscriptListPEP
>
> It's not linked to by any other pages on the wiki. Is there a reason it
> wasn't added to the peps repository?
Perhaps the author forgot to sub
[EMAIL PROTECTED] wrote:
> Noam Raphael posted an empty subscript PEP on the Python Wiki:
>
> http://wiki.python.org/moin/EmptySubscriptListPEP
>
> It's not linked to by any other pages on the wiki. Is there a reason it
> wasn't added to the peps repository?
The most likely reason is that h
Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> [ Many useful answers ]
>
> Thanks very much! That helps. Here are a few points where we are at
> cross-purposes.
[snip]
> I believe that, using the above approach, it would be possible to
> achieve good eff
Bruce Christensen wrote:
> Thanks! That helps a lot. PEP 307 and the pickle module docs describe the end
> result pretty well, but they don't always make it clear where things are
> implemented. I'm trying to make sure that I'm getting the right interaction
> between object.__reduce(_ex)__, pickle,
Noam Raphael posted an empty subscript PEP on the Python Wiki:
http://wiki.python.org/moin/EmptySubscriptListPEP
It's not linked to by any other pages on the wiki. Is there a reason it
wasn't added to the peps repository?
Skip
___
Python-Dev maili
Brett Cannon wrote:
> The question is how long do we wait for the expat developers to patch
> and do a micro release? Do we just leave this possible crasher in and
> just rely entirely on the expat developers, or do we patch our copy and
> use that until they get around to doing their next version
Josiah Carlson wrote:
> Any pointers as to why there is a difference would be appreciated.
This was fixed in r35540, r35541, r35542, r35543, by Nick Bastin
and Armin Rigo, in response to #765624. Enough pointers :-?
Regards,
Martin
___
Python-Dev maili
On 6/30/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Sun, 25 Jun 2006 17:51:17 -0700, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> >On 6/24/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >> >Actually, your application *was* pretty close to being broken a few
> >> >weeks ago, wh
On Sun, 25 Jun 2006 17:51:17 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 6/24/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>> >Actually, your application *was* pretty close to being broken a few
>> >weeks ago, when Guido wanted to drop the requirement that a package
>> >must contai
Kristján V. Jónsson wrote:
> As a side note, is there a finalization order list for imported modules?
If they are Python modules, more or less, yes. Extension modules
cannot currently be finalized (I plan to change that for Py3k).
See PyImport_Cleanup for the precise algorithm used; there are
patc
Thomas Heller wrote:
> - Do I need special rights to call 'svnadmin load' to import this dumpfile
> into Python SVN, or are the normal commit rights sufficient?
It's called "svnadmin" for a reason :-)
Neal Norwitz or myself will have to do that; we need to do it on the
repository machine locall
"Tim Peters" <[EMAIL PROTECTED]> wrote:
[ Many useful answers ]
Thanks very much! That helps. Here are a few points where we are at
cross-purposes.
I am talking about the C level. What I am thinking of is the standard
method of implementing the complicated housekeeping of a class (e.g.
inheri
Tim Peters wrote:
> I hope you've read PEP 307:
I have. Thanks to you and Guido for writing it! It's been a huge help.
> The implementation is more like:
[snip]
Thanks! That helps a lot. PEP 307 and the pickle module docs describe the end
result pretty well, but they don't always make it clear
James Y Knight wrote:
> On Jun 30, 2006, at 3:05 AM, Neal Norwitz wrote:
>> If there are any bugs you think should be considered show stoppers,
>> mail them to the list and I will update the PEP.
>
> I just submitted http://python.org/sf/1515169 for the ImportWarning
> issue previously discussed
[Nick Maclaren]
> I Have been thinking about software floating point, and there are
> some aspects of Python and decimal that puzzle me. Basically, they
> are things that are wanted for this sort of thing and seem to be
> done in very contorted ways, so I may have missed something.
>
> Firstly, ca
[EMAIL PROTECTED] wrote:
> Ping> The question is, what behaviour is preferable for this code:
>
> Ping> g = 1
> Ping> def f():
> Ping> g += 1
>
> Ping> f()
>
> If you treat "g += 1" as "g = g + 1" then it should create a local variable
> with a value of 2.
Aahz <[EMAIL PROTECTED]> wrote:
>
> Without answering your specific questions, keep in mind that Python and
> Python-C code are very different things. The current Decimal
> implementation was designed to be *readable* and efficient *Python* code.
> For a look at what the Python-C implementation o
On Fri, Jun 30, 2006, Nick Maclaren wrote:
>
> I Have been thinking about software floating point, and there are
> some aspects of Python and decimal that puzzle me. Basically, they
> are things that are wanted for this sort of thing and seem to be
> done in very contorted ways, so I may have miss
I Have been thinking about software floating point, and there are
some aspects of Python and decimal that puzzle me. Basically, they
are things that are wanted for this sort of thing and seem to be
done in very contorted ways, so I may have missed something.
Firstly, can Python C code assume no C
On Friday 30 June 2006 14:19, Brett Cannon wrote:
> The question is how long do we wait for the expat developers to patch and
> do a micro release? Do we just leave this possible crasher in and just
> rely entirely on the expat developers, or do we patch our copy and use
> that until they get
Hi,
the following patch tries to fix the LOAD_CONST POP_TOP optimization
lost in 2.5 (bug #1333982).
An example for this is:
def f():
'a' # docstring
'b'
Georg
PS: Hmm. While looking, I see that 2.4 doesn't optimize away other constants
like
def g():
1
Index: Python/compile.c
===
[Bruce Christensen]
> So just to be clear, is it something like this?
I hope you've read PEP 307:
http://www.python.org/dev/peps/pep-0307/
That's where __reduce_ex__ was introduced (along with all the rest of
pickle protocol 2).
> class object:
> def __reduce__(self):
> return c
Kristján V. Jónsson ccpgames.com> writes:
> Can this not be resolved by carefully adjusting the order of finalization?
Absolutely. This is exactly what I did in my "interned" patch and this
is what prompted my proposal.
> If code can be bootstrapped it can be strootbapped.
Agree. However, the
Lib/test/crashers/xml_parsers.py is a crasher that involves expat (bug report at http://python.org/sf/1296433). What is at issue here is that there is a 'for' loop in expat where the status of the parser is not checked. Because of this, the loop continues on its merry way, which is a problem beca
On 6/30/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
Hi Brett,On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote:> 1) Is removing 'file' from the builtins dict in PyInterpreterState (and> maybe some other things) going to be safe enough to sufficiently hide 'file'
> confidently (short of som
Hi Brett,
On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote:
> 1) Is removing 'file' from the builtins dict in PyInterpreterState (and
> maybe some other things) going to be safe enough to sufficiently hide 'file'
> confidently (short of someone being stupid in their C extension module
Please do help us improve the docs. Patches are the best (most likely
to be applied the fastest), bug reports are welcome too. Especially
when they contain your preferred wording in the text.
n
--
On 6/30/06, Bruce Christensen <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > on the other h
Fredrik Lundh wrote:
> on the other hand, it would be nice if someone actually used Bruce's
questions
> and the clarifications to update the documentation; the ideas behind
the
> internal pickle interfaces aren't exactly obvious, even if you have
the
> source.
I've found a few other places where t
Thanks for your responses, Martin!
Martin v. Löwis wrote:
> Bruce Christensen wrote:
> > - Where are object.__reduce__ and object.__reduce_ex__ defined, and how
> > does copy_reg._reduce_ex fit into the picture?
>
> See
>
> http://docs.python.org/lib/node69.html
So just to be clear, is it som
On 6/30/06, Frank Wierzbicki <[EMAIL PROTECTED]> wrote:
Hello all,According to the thread that includeshttp://mail.python.org/pipermail/python-dev/2006-June/065727.htmlthere will be some effort in
2.6 to make the tests in Python moreconsistent. I would like to help with that effort, partly to sne
> I think it should increment (i.e. rebind) g, for the same reason that
>
> g = [1]
> def f():
> g[0] += 1
> f()
>
> rebinds g[0].
I saw messages out of sequence and did not realize that this would be a
change in behavior from 2.4. Sigh.
I hope Py3000 has lexica
> The question is, what behaviour is preferable for this code:
>
> g = 1
> def f():
> g += 1
>
> f()
>
> Should this raise an UnboundLocalError or should it increment g?
I think it should increment (i.e. rebind) g, for the same reason that
g = [1]
def f():
I've previously asked on python-list, but have recieved no responses or
explanations. Maybe someone here with a better memory can help, and I
apologize for asking a somewhat off-topic question about such an archaic
version of Python.
According to my reading of Python 2.3 docs, the call to goo()
Jeroen Ruigrok van der Werven wrote:
> On 6/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> We should remove/change this comment. It is utterly misleading.
>
> To a warning/error stating that you miss a compiler?
Correct: that you miss VS 2003, or should request mingw.
>> Forget about Vis
On Jun 30, 2006, at 3:05 AM, Neal Norwitz wrote:
> If there are any bugs you think should be considered show stoppers,
> mail them to the list and I will update the PEP.
I just submitted http://python.org/sf/1515169 for the ImportWarning
issue previously discussed here. IMO it's important.
Jame
Hello all,
According to the thread that includes
http://mail.python.org/pipermail/python-dev/2006-June/065727.html
there will be some effort in 2.6 to make the tests in Python more
consistent. I would like to help with that effort, partly to sneak in
some checks for CPython internal tests that sh
On Fri, 30 Jun 2006 00:05:10 -0700, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>I'm glad to see Anthony ratcheting down. At this point, we need to be
>fixing bugs and improving doc. Maybe Anthony and I should have a
>contest to see who can revert the most changes. :-)
>
>There are at least 6 bugs th
Ping> The question is, what behaviour is preferable for this code:
Ping> g = 1
Ping> def f():
Ping> g += 1
Ping> f()
If you treat "g += 1" as "g = g + 1" then it should create a local variable
with a value of 2. There being no global statement in f() it
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
>
>
[Ka-Ping Yee, on
http://www.python.org/dev/peps/pep-0356/
]
> Among them is this one:
>
> Incorrect LOAD/STORE_GLOBAL generation
> http://python.org/sf/1501934
>
> The question is, what behaviour is preferable for this code:
>
> g = 1
> def f():
> g += 1
>
> f()
>
> Sh
On 6/30/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> > Forget about Visual Studio 8 and .NET 2.0. It won't help here.
>
> I only have .NET 1.1 and 2.0 and Visual Studio 2005 (8) installed. Why
> should I forget about it? Is Python compiled with much older compilers
> and thus unab
>
> That was a purely altruistic proposal. I've already
> discovered that sets are finalized and that some code that
> works with dict emulating a set may not work with a set. It
> will not make much difference for me if my proposal will be
> implemented in 2.6 or even in 3.0, but the soo
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
The question is, what behaviour is preferable for this co
Martin v. Löwis schrieb:
> Thomas Heller wrote:
>> What I did was at a certain time develop in the 'branch_1_0' branch, leaving
>> HEAD for experimental work. Later I decided that this was wrong, cvs
>> removed all
>> files in HEAD, and added them back from a branch_1_0 checkout. Maybe doing
>>
Hi,
On Mon, Jun 26, 2006 at 12:23:00PM -0700, Guido van Rossum wrote:
> Feedback (also about misrepresentation of alternatives I don't favor)
> is most welcome, either to me directly or as a followup to this post.
So my 2 cents, particularly about when things are computed and ways to
control that
I'm glad to see Anthony ratcheting down. At this point, we need to be
fixing bugs and improving doc. Maybe Anthony and I should have a
contest to see who can revert the most changes. :-)
There are at least 6 bugs that really, really need to be fixed before
release. Several of these are AST bugs
Martin v. Löwis wrote:
>> In developing a cPickle module for IronPython that's as compatible as
>> possible with CPython, these questions have come up:
>
> [I wish you were allowed to read the source code of Python]
on the other hand, it would be nice if someone actually used Bruce's questions
an
85 matches
Mail list logo
