Re: [Python-Dev] LOAD_CONST POP_TOP

[Armin Rigo]

Hi Georg,

On Fri, Jun 30, 2006 at 08:39:13PM +0200, Georg Brandl wrote:
> +   case LOAD_CONST:
> +   cumlc = lastlc + 1;
> +   /* Skip over LOAD_CONST POP_TOP */
> +   if (codestr[i+3] == POP_TOP) {

This is missing a ISBASICBLOCK() check.  It makes the following example
segfault:

a = 5
for i in range(1000):
a or 4

Attached an updated patch to the SF tracker.


A bientot,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2.5 and beyond

[jan-python]

Hi everyone, Even though I'm new on this list I think I've got something
sensible to say on this one. (I've been following this list a bit through the
archives)

Andrew Koenig wrote:
> You seem to be right -- the problem is not that Python is lexically   scoped,
> but that when you define a variable with =, it leaks out into the
> surrounding function scope.

> So maybe what I meant when I asked for lexical scopes was two things:
>
> 1) Every indentation level should be a scope;
> 2) In general, variable definitions should not leak into
>surrounding scopes.
>
> I realize that (2) is too simplistic.  Someone who writes

I believe the problem has nothing to do with how many scopes a block/function
definition has, but with what the lambda does with the scope it's given.
Currently it remembers the block and looks up the nescessary variables in it
when it's invoked. I think it shoud should have just taken the values of the
needed variables and rememberd those as it's own local variables. So 
the closed
over variables become just local variables initialised to the value 
they have in
the outer scope.

Without having any blocks to be confused about, I think this is
counterintuitive
as well:

>>> x = 1
>>> f = lambda: x
>>> x = 2
>>> g = lambda: x
>>> f()
2
>>> g()
2

I think it should have been:

>>> f()
1
>>> g()
2

Using the lambda x=x: x trick gives exactly this behaviour because it
apparently does copy the value of x. As far as I can see it also solves the
>>> for i in range(10):
  ... a.append(lambda: i)
case, and other similar examples.
(However, this would probably be a to big change for 2.5)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.5 and beyond

[Phillip J. Eby]

At 01:58 PM 7/2/2006 +0200, [EMAIL PROTECTED] wrote:
>I believe the problem has nothing to do with how many scopes a block/function
>definition has, but with what the lambda does with the scope it's given.
>Currently it remembers the block and looks up the nescessary variables in it
>when it's invoked. I think it shoud should have just taken the values of the
>needed variables and rememberd those as it's own local variables. So
>the closed
>over variables become just local variables initialised to the value
>they have in
>the outer scope.

That won't work.  Consider this code, that's perfectly valid Python today:

def foo():
def bar():
print x
for x in range(10):
bar()

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Another 2.5 bug candidate?

[A.M. Kuchling]

http://www.python.org/sf/1488934 argues that Python's use of fwrite()
has incorrect error checking; this most affects file.write(), but
there are other uses of fwrite() in the core.  It seems fwrite() can
return N bytes written even if an error occurred, and the code needs
to also check ferror(f->fp).

At the last sprint I tried to assemble a small test case to exhibit
the problem but failed.  The reporter's test case uses SSH, and I did
verify that Python does loop infinitely if executed under SSH, but a
test case would need to work without SSH.

Should this be fixed in 2.5?  I'm nervous about such a change to error
handling without a test case to add; maybe it'll cause problems on one
of our platforms.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Another 2.5 bug candidate?

[Nick Maclaren]

"A.M. Kuchling" <[EMAIL PROTECTED]> wrote:
> 
> http://www.python.org/sf/1488934 argues that Python's use of fwrite()
> has incorrect error checking; this most affects file.write(), but
> there are other uses of fwrite() in the core.  It seems fwrite() can
> return N bytes written even if an error occurred, and the code needs
> to also check ferror(f->fp).
> 
> At the last sprint I tried to assemble a small test case to exhibit
> the problem but failed.  The reporter's test case uses SSH, and I did
> verify that Python does loop infinitely if executed under SSH, but a
> test case would need to work without SSH.
> 
> Should this be fixed in 2.5?  I'm nervous about such a change to error
> handling without a test case to add; maybe it'll cause problems on one
> of our platforms.

So would assembling a test case.  NOTHING will cause ferror to return
True that isn't classed as undefined behaviour, and therefore may fail
on some platforms.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lexical scoping in Python 3k

[Ka-Ping Yee]

On Sat, 1 Jul 2006, Andrew Koenig wrote:
> I'd rather see a simpler rule: = never defines a variable in a surrounding
> scope.  If you want to affect the binding of such a variable, you have to
> define it explicitly in the scope in which you want it.
>
> Example:
>
>   x = 42
>   def f():
>   x = 123 # rebinds x as defined above
>   y = 123 # defines local variable
>   f()
>   print x # prints 123
>   print y # error -- y not defined
>
> Yes, I know that rule is too simplistic.  But I think I'd still prefer it to
> the way things are now.

I agree with you that this is a nicer and more consistent rule.
What do you think of the proposal for a keyword to say "don't rebind"?
It would achieve the same distinction you're aiming for above, but
without the drastic incompatibility with today's Python.

This has been previously discussed as "change the meaning of 'global'
to mean 'not local'":

http://mail.python.org/pipermail/python-dev/2006-February/061568.html

http://mail.python.org/pipermail/python-dev/2006-July/066908.html

I support this proposal, though i would prefer a clearer keyword
such as "outer x" or "nonlocal x".  If we can't agree on another
keyword (or can't afford to spend one more keyword), i'm willing
to support "global" for this purpose.


-- ?!ng
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lexical scoping in Python 3k

[Greg Ewing]

Josiah Carlson wrote:

> If the only code that benefits from such changes are "very *simple*",
> then I think that says something about its necessity.

The point is that they're only "very simple" if you
can write them using access to an outer scope. Without
that ability, they become less simple, less efficient,
more convoluted, harder to follow, etc.

Also I don't buy the argument that something has to
be useful for big, complicated things in order to be
worth having in the language.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.5 and beyond

[Greg Ewing]

Giovanni Bajo wrote:
> I believe that names in
> lambdas/nested-functions referring to local names in the outer scope should
> really be bound at function definition time

No, you don't want that, because it would make functions that
call each other very awkward to arrange.

> And it's also handy that the iteration variable of the for loop is
> accessible after the for loop is terminated (in fact, this specific
> behaviour is already listed among the wont-change for Py3k).

I'd just like to point out that the create-a-new-cell
behaviour that I have proposed for loop variables
*preserves* this ability!

   for new i in range(10):
 ...
   print i

will still print 9.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.5 and beyond

[Greg Ewing]

Tim Peters wrote:

> Scheme has no loops in Python's sense --
> things like "do" are shorthand for expressing stylized recursion

But it does have foreach and map, which are the
moral equivalent of Python's for-loops and list
comprehensions. The body is a lambda which takes
the loop variable as a parameter, thus providing
the extra level of scope. Recursion isn't needed.

> When people talk about giving a Python for-loop vrbl its own scope,
> they generally don't mean a new scope on _each iteration_,

But that's exactly what you *do* need in order for
a for-loop with a lambda in it to behave intuitively.
If that's not what people mean, it's because they
don't fully understand what they really mean to
mean. :-)

BTW, I'm not suggesting that a new stack frame
gets allocated for every iteration -- all you need
is a cell.

> about the same as creating a nested block with
> its own autos in C.

Analogies with C aren't very helpful here, because
it doesn't have closures, so it's only a matter of
visibility, not lifetime.

 > creating a new scope on each iteration
 > sounds hard to explain in Python.

But is it harder to explain than the reason someone's
loop-with-a-lambda doesn't do what they expect?

BTW, I wouldn't explain it by saying it creates a new
scope, I'd say it creates a new binding on each
iteration, or something like that.

In my earlier proposal, you would actually say that
explicitly, with something like

   for new i in range(10):
 ...

> Abusing the default-argument machinery to capture current bindings is
> never necessary, and _is_ abuse.

But it's abuse that still happens, because although
scoping has been fixed, other parts of the story are
still missing.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal to eliminate PySet_Fini

[Jack Diederich]

On Tue, Jun 27, 2006 at 02:09:19PM -0400, Alexander Belopolsky wrote:
> Setobject code allocates several internal objects on the heap that are
> cleaned up by the PySet_Fini function.  This is a fine design choice,
> but it often makes debugging applications with embedded python more
> difficult.
> 
> I propose to eliminate the need for PySet_Fini as follows:
> 
> 1. Make dummy and emptyfrozenset static objects similar to Py_None
> 2. Eliminate the free sets reuse scheme.
> 
> The second proposal is probably more controversial, but is there any
> real benefit from that scheme when pymalloc is enabled?

These are optimizations and not likely to go away. tuples especially get
reused frequently.  In the case of tuples you can #define MAXSAVEDTUPLES
to zero in a custom python build to disable free-listing.  You can submit
a patch that #ifdef'd the other free list in a similar way (sets don't
currently have the ifdef check, for instance) and hope it gets accepted.
I don't see why it wouldn't.

PyObject_MALLOC does a good job of reusing small allocations but it
can't quite manage the same speed as a free list, especially for things that
have some extra setup involved (tuples have a free list for each length).

-Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] bug #1513646

[Yi Ding]

Hi guys,

I filed this bug but sourceforge is down so I can't update it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1513646&group_id=5470&atid=105470

Basically, os.access returns the wrong result for W_OK, and that's
because instead of using & it uses && to see if the file is read only.

diff -urdN accessfix/python/Modules/posixmodule.c
stock/python/Modules/posixmodule.c
--- accessfix/python/Modules/posixmodule.c  2006-06-28
14:15:31.368649100 -0700
+++ stock/python/Modules/posixmodule.c  2006-06-28 14:20:26.138047100 -0700
@@ -1402,7 +1402,7 @@
return PyBool_FromLong(0);
/* Access is possible if either write access wasn't requested, or
   the file isn't read-only. */
-   return PyBool_FromLong(!(mode & 2) || !(attr &&
FILE_ATTRIBUTE_READONLY));
+   return PyBool_FromLong(!(mode & 2) || !(attr &
FILE_ATTRIBUTE_READONLY));
 #else
int res;
if (!PyArg_ParseTuple(args, "eti:access",

Thanks,
Yi
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] DRAFT: python-dev summary for 2006-06-01 to 2006-06-15

[Steven Bethard]

Here's the summary for the first half of June.  Thanks in advance for
your comments and corrections!


=
Announcements
=

---
Python 2.5 schedule
---

Python 2.5 is moving steadily towards its next release.  See `PEP
356`_ for more details and the full schedule.

.. _PEP 356: http://www.python.org/dev/peps/pep-0356/

Contributing threads:

- `beta1 coming real soon
`__
- `2.5 issues need resolving in a few days
`__

---
Request for Bug Trackers to replace SourceForge
---

The Python Software Foundation's Infrastructure committee asked for
suggestions for tracker systems that could replace SourceForge. The
minimum requirements are:

* Can import SourceForge data
* Can export data
* Has an email interface

and if you'd like to suggest a particular tracker system all you need to do is:

* Install a test tracker
* Import the `SourceForge data dump`_
* Make the `Infrastructure committee members`_ administrators of the tracker
* Add your tracker to the `wiki page`_
* Email `the Infrastructure committee`_

Be sure to check the `wiki page`_ for additional information.

.. _SourceForge data dump: http://effbot.org/zone/sandbox-sourceforge.htm
.. _Infrastructure committee members:
http://wiki.python.org/moin/PythonSoftwareFoundationCommittees#infrastructure-committee-ic
.. _wiki page: http://wiki.python.org/moin/CallForTrackers
.. _the Infrastructure committee: [EMAIL PROTECTED]

Contributing thread:

- `Request for trackers to evaluate as SF replacement for Python
development 
`__


=
Summaries
=


Getting more comparable results from pybench


Skip Montanaro mentioned that the NeedForSpeed_ folks had some trouble
with the pybench_ string and unicode tests. In some discussions both
on the checkins list and off-list, Fredrik Lundh had concluded that
stringbench more reliably reported performance than pybench. There was
then a long discussion about how to improve pybench including:

* Using time.clock() on Windows and time.time() on Linux. This was
accompanied by a long debate about whether to use wall-time or process
time.  Both wall time and process time can see interference from other
programs running at the same time; wall time because the time consumed
by other programs running at the same time is also counted, and
process time because it is sampled so that other processes can charge
their time to the running process by using less than a full time
slice. In general, the answer was to use the timer with the best
resolution.

* Using the minimum time rather than the average. Andrew Dalke
explained that timing results do not have a Gaussian distribution
(they have more of a gamma distribution) and provided some graphs
generated on his machine to demonstrate this. Since the slower runs
are typically caused by other things running at the same time (which
is pretty much unpredictable), it's much better to report the fastest
run, which should more consistently approximate the best possible
time.

* Making sure to use an appropriate warp factor. Marc-Andre Lemburg
explained that each testing round of pybench is expected to take
around 20-50 seconds. If rounds are much shorter than this, pybench's
warp factor should be adjusted until they are long enough.

At the end of the thread, Marc-Andre checked in pybench_ 2.0, which
included the improvements suggested above.

.. _NeedForSpeed: http://wiki.python.org/moin/NeedForSpeed
.. _pybench: http://svn.python.org/view/python/trunk/Tools/pybench/
.. _stringbench: http://svn.python.org/view/sandbox/trunk/stringbench/

Contributing threads:

- `Python Benchmarks
`__
- `Python Benchmarks
`__

---
PEP 360: Externally Maintained Packages
---

After checking wsgiref into the Python repository, Phillip J. Eby
requested in `PEP 360`_ that patches to wsgiref be passed to him
before being committed on the trunk. After a number of changes were
committed to the trunk and he had to go through a complicated two-way
merge, he complained that people were not following the posted
procedures. Guido suggested that `PEP 360`_ was a mistake, and that
whenever possible, development for any module in the stdlib should be
done in the Python trunk, not externally. He also requested that the
PEP indicate that even for externally maintained modules, bugfixes and
ordinary maintenance should be allowed on the trunk so that bugs in
external modules don't hold up Py

Re: [Python-Dev] Lexical scoping in Python 3k

[Josiah Carlson]

Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > If the only code that benefits from such changes are "very *simple*",
> > then I think that says something about its necessity.
> 
> The point is that they're only "very simple" if you
> can write them using access to an outer scope. Without
> that ability, they become less simple, less efficient,
> more convoluted, harder to follow, etc.

As is known and has been stated, assigning to a parent scope can be
emulated in various ways, either through an explicit namespace object, or
through a namespace list.


> Also I don't buy the argument that something has to
> be useful for big, complicated things in order to be
> worth having in the language.

I never claimed that something needed to be useful for "big, complicated
things" in order to be worth having in the language.  To be explicit, if
nontrivial code isn't improved, that doesn't necessarily mean that the
feature is useless.  However, if the feature is really only useful for
generally trivial cases *without* the feature, then making them even
more trivial, I think, is a bit of over optimization.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lexical scoping in Python 3k

[Guido van Rossum]

On 7/3/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Josiah Carlson wrote:
> > > If the only code that benefits from such changes are "very *simple*",
> > > then I think that says something about its necessity.
> >
> > The point is that they're only "very simple" if you
> > can write them using access to an outer scope. Without
> > that ability, they become less simple, less efficient,
> > more convoluted, harder to follow, etc.
>
> As is known and has been stated, assigning to a parent scope can be
> emulated in various ways, either through an explicit namespace object, or
> through a namespace list.

And the fact that this desire and need remains, even amongst people
who should know better, suggests that it may be worth supporting it
more directly, as the current work-arounds ain't pretty.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lexical scoping in Python 3k

[Josiah Carlson]

"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> 
> On 7/3/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > Josiah Carlson wrote:
> > > > If the only code that benefits from such changes are "very *simple*",
> > > > then I think that says something about its necessity.
> > >
> > > The point is that they're only "very simple" if you
> > > can write them using access to an outer scope. Without
> > > that ability, they become less simple, less efficient,
> > > more convoluted, harder to follow, etc.
> >
> > As is known and has been stated, assigning to a parent scope can be
> > emulated in various ways, either through an explicit namespace object, or
> > through a namespace list.
> 
> And the fact that this desire and need remains, even amongst people
> who should know better, suggests that it may be worth supporting it
> more directly, as the current work-arounds ain't pretty.


Perhaps not pretty, but not wholly ugly either.  Or expressed another
way, it's a wart, but the wart isn't 1" across on a forehead, it's
fairly small and tucked away on an elbow.

I had hoped that there would be a response to my second (and I believe
more applicable statement); "if the feature is really only useful for
generally trivial cases *without* the feature, then making them even
more trivial, I think, is a bit of over optimization."

As for a solution, I find the "global means 'not local'" proposition is
the least undesireable of the possibilities.  It suffers from a change
in semantics and potential name masking issues, but I don't believe
these are any more serious than normal global masking for the former,
and the latter is solvable with a __future__ (at least for 2.6). I'm a
solid -0 on this particular proposition, which is far better than the -1
I am on all of the other recent lexical scoping propositions.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal to eliminate PySet_Fini

[Martin v. Löwis]

Jack Diederich wrote:
> PyObject_MALLOC does a good job of reusing small allocations but it
> can't quite manage the same speed as a free list, especially for things that
> have some extra setup involved (tuples have a free list for each length).

I would question that statement, for any practical purposed. The cost of
tuple comes from setting the elements to NULL, and that has to be done
regardless of whether they were allocated new or came from the list.
Likewise, the GC management has to be done regardless. So I expect that
the speedup is rather minor, and not worth it.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com