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
and the
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
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
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
this was
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 sooner
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 unable to
[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()
Should this
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
The question
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 must not
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 that
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
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.
James
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 Visual Studio
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 lexical
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 sneak
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 something
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 the
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 hand,
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
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 someone
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
Kristján V. Jónsson kristjan at 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.
[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
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
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
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 missed
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 of
[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.
py g = 1
py def
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
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.
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 locally.
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
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 contain an __init__
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, when Guido wanted
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
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
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
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,
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 efficiency with
[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 he
[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 submit
[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 307 and
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. I would
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-friendly
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 that
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 Fri, 30 Jun 2006, Brett Cannon wrote:
On 6/30/06, Armin Rigo [EMAIL PROTECTED] wrote:
object.__subclasses__()
[..., type 'file']
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 been my
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
unittest.
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 la
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__() [..., type 'file']
Maybe this one won't work if __subclasses__ is forbidden, but in general I think there *will* be a way to find
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 since I
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
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). Perhaps
[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]
That's not a
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 program.
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,
variable
[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,
def
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
binding of
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, while
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():
[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
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 that at all
[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 excruciating abuses of lexical
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 mailing list
[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 from excruciating abuses
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] wrote:
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.
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.org
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
people to
use the i=i
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]
[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 above code
generated
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't
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
73 matches
Mail list logo
