Hi.
[Mark Hammond]
> The point isn't about my suffering as such. The point is more that
> python-dev owns a tiny amount of the code out there, and I don't believe we
> should put Python's users through this.
>
> Sure - I would be happy to "upgrade" all the win32all code, no problem. I
> am also happy to live in the bleeding edge and take some pain that will
> cause.
>
> The issue is simply the user base, and giving Python a reputation of not
> being able to painlessly upgrade even dot revisions.
I agree with all this.
[As I imagined explicit syntax did not catch up and would require
lot of discussions.]
[GvR]
> > Another way is to use special rules
> > (similar to those for class defs), e.g. having
> >
> > <frag>
> > y=3
> > def f():
> > exec "y=2"
> > def g():
> > return y
> > return g()
> >
> > print f()
> > </frag>
> >
> > # print 3.
> >
> > Is that confusing for users? maybe they will more naturally expect 2
> > as outcome (given nested scopes).
>
> This seems the best compromise to me. It will lead to the least
> broken code, because this is the behavior that we had before nested
> scopes! It is also quite easy to implement given the current
> implementation, I believe.
>
> Maybe we could introduce a warning rather than an error for this
> situation though, because even if this behavior is clearly documented,
> it will still be confusing to some, so it is better if we outlaw it in
> some future version.
>
Yes this can be easy to implement but more confusing situations can arise:
<frag>
y=3
def f():
y=9
exec "y=2"
def g():
return y
return y,g()
print f()
</frag>
What should this print? the situation leads not to a canonical solution
as class def scopes.
or
<frag>
def f():
from foo import *
def g():
return y
return g()
print f()
</frag>
[Mark Hammond]
> > This probably won't be a very popular suggestion, but how about pulling
> > nested scopes (I assume they are at the root of the problem)
> > until this can be solved cleanly?
>
> Agreed. While I think nested scopes are kinda cool, I have lived without
> them, and really without missing them, for years. At the moment the cure
> appears worse then the symptoms in at least a few cases. If nothing else,
> it compromises the elegant simplicity of Python that drew me here in the
> first place!
>
> Assuming that people really _do_ want this feature, IMO the bar should be
> raised so there are _zero_ backward compatibility issues.
I don't say anything about pulling nested scopes (I don't think my opinion
can change things in this respect)
but I should insist that without explicit syntax IMO raising the bar
has a too high impl cost (both performance and complexity) or creates
confusion.
[Andrew Kuchling]
> >Assuming that people really _do_ want this feature, IMO the bar should be
> >raised so there are _zero_ backward compatibility issues.
>
> Even at the cost of additional implementation complexity? At the cost
> of having to learn "scopes are nested, unless you do these two things
> in which case they're not"?
>
> Let's not waffle. If nested scopes are worth doing, they're worth
> breaking code. Either leave exec and from..import illegal, or back
> out nested scopes, or think of some better solution, but let's not
> introduce complicated backward compatibility hacks.
IMO breaking code would be ok if we issue warnings today and implement
nested scopes issuing errors tomorrow. But this is simply a statement
about principles and raised impression.
IMO import * in an inner scope should end up being an error,
not sure about 'exec's.
We will need a final BDFL statement.
regards, Samuele Pedroni.
I have just had the experience of writing a bunch
of expressions of the form
"create index %(table)s_lid1_idx on %(table)s(%(lid1)s)" % params
and found myself getting quite confused by all the parentheses
and "s" suffixes. I would *really* like to be able to write
this as
"create index %{table}_lid1_idx on %{table}(%{lid1})" % params
which I find to be much easier on the eyes.
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg(a)cosc.canterbury.ac.nz +--------------------------------------+
Hi colleagues,
this is my second attempt to get rid of the f_tstate field
in frames. I need to find every user of this field.
What am I talking about?
Well, Python always has a thread state variable which
is a unique handle to the current thread. This variable
is accessed in many places, and there exists a fast macro
to get at it.
Every executing Python frame also gets a copy on creation.
In some cases, this frame->f_tstate field is used,
in other cases the current tstate variable is used.
If this sounds foreign to you, please stop reading here.
-------------------------------------------------------------
I would like to get rid of the frame->f_tstate, and I'm trying
to find out if there is a need for it. I don't need it,
for Stackless, it is the opposite, it disturbs.
There was a small thread about this in June this year, where
Guido convinced me that it is possible to create a traceback
on a frame that comes from a different thread.
http://mail.python.org/pipermail/python-dev/2003-June/036254.html
Ok, this is in fact possible, although I don't think
anybody has a need for this.
My question to all extension writers is this:
If you use frame->f_tstate at all, do you use it just
because it is handy, or do you want to use it for
some other purpose?
One purpose could be that you really want to create a traceback
on a different than the current thread. I have never seen this,
but who knows, so that's why I'm asking the Python world.
In most cases, a traceback will be created on a frame
that is currently processd or just has been processed.
Accessing a frame of a different thread that is being processed
might make sense for special debugger cases.
My proposal is
--------------
a) change semantics of PytraceBack_Here to use the current tstate.
b) if such a special purpose exists, create a new function for it.
c) if urgent, different needs exist to keep f_tstate,
then let's forget about this proposal.
Especially for Stackless, I'd be keen of getting rid of this.
thanks for input -- chris
--
Christian Tismer :^) <mailto:tismer@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3.3 (release candidate 1).
Python 2.3.3 is a bug-fix release of Python 2.3. A couple of serious
bugs related to weakrefs and the cyclic garbage collector have been
fixed, along with a number of bugs in the standard library. See the
release notes on the web page for more details.
For more information on Python 2.3.3c1, including download links for
various platforms, release notes, and known issues, please see
http://www.python.org/2.3.3
Highlights of this new release include:
- A couple of serious bugs in the interactions of weakrefs and
cyclic GC have been squashed.
- At shutdown, the second call to the cyclic garbage collector has
been removed. This caused more problems than it solved.
- The xml.parsers.expat module now provides Expat 1.95.7.
- urllib2's HTTP Digest Auth support works again.
- See http://www.python.org/2.3.3/NEWS.html for other bugfixes.
Highlights of the previous major Python release (2.3) are available
from the Python 2.3 page, at
http://www.python.org/2.3/highlights.html
A final version of Python 2.3.3 should follow in a couple of weeks,
just in time for your Christmas stockings.
Enjoy the new release,
Anthony
Anthony Baxter
anthony(a)python.org
Python 2.3.x Release Manager
(on behalf of the entire python-dev team)
Dan reported a problem with the benchmark on Mac OS X:
> > Hrm. On my OS X laptop:
> >
> > lir:~/Desktop/parrotbench dan$ python -O
> > Python 2.3 (#1, Sep 13 2003, 00:49:11)
> > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import b
> > --> iteration 0
> > --> b0
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > File "b.py", line 12, in ?
> > b0.main()
> > File "b0.py", line 893, in main
> > checkoutput(4201300315)
> > File "b0.py", line 763, in checkoutput
> > check(strhash(outputtext), n)
> > File "b0.py", line 3, in check
> > raise AssertionError("%.30r != %.30r" % (a, b))
> > AssertionError: 503203581L != 4201300315L
> > >>>
After some off-line email exchanges I think I have a fix for this
behavior, which must have to do with a different length of the
addresses shown in the default repr(), e.g. "<Foo object at 0xffff>".
Version 1.0.1 of the benchmark is at the same place as before:
ftp://python.org/pub/python/parrotbench/parrotbench.tgz
(You can tell whether you have the fixed version by looking at first
line of README.txt; if it says "Parrot benchmark 1.0.1" you do.)
I haven't heard back from Dan, but I assume that the fix works.
Happy New Year everyone!
--Guido van Rossum (home page: http://www.python.org/~guido/)
In my own sandbox, I have prepared project files for VC.NET.
Unless there are any strong objections, I'd like to switch
over to VC.NET shortly, disabling VC6 builds. In the process,
I will also update the build dependencies to more recent
versions of several packages.
Regards,
Martin
According to PEP-0004 and PEP-0320, the audioop module is deprecated,
and scheduled for removal in 2.4. I hadn't noticed this before, but
I'd like to ask that it be kept. I've a number of pieces of code using
it - both internal (our unified messaging server makes heavy use of
it) and external (the shtoom python SIP phone uses it).
Anthony
I have some fixes for the imageop module to make it work on systems with
a different byte-order than IRIX (e.g. Linux). Shall I check them in or
is it not worth it for such an old module? Anything else that needs to
be changed when I check this in?
The fixes of course will result in different results on Linux than
before, so that's the main reason for asking.
--
Sjoerd Mullender <sjoerd(a)acm.org>
The utime() call is failing for one of the Unicode file names.
build> ./python ../Lib/test/test_unicode_file.py
test_directories (__main__.TestUnicodeFiles) ... ok
test_equivalent_files (__main__.TestUnicodeFiles) ... ok
test_single_files (__main__.TestUnicodeFiles) ...
'@test-\xc3\xa0\xc3\xb2'
'@test-\xc3\xa0\xc3\xb2'
u'@test-\xe0\xf2'
ERROR
======================================================================
ERROR: test_single_files (__main__.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
File "../Lib/test/test_unicode_file.py", line 143, in
test_single_files
self._test_single(TESTFN_UNICODE)
File "../Lib/test/test_unicode_file.py", line 117, in _test_single
self._do_single(filename)
File "../Lib/test/test_unicode_file.py", line 33, in _do_single
os.utime(filename, None)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
6-7: ordinal not in range(128)
I'm running on a RH9 system.
I see that the code hasn't changed since the beginning of the month, so
I'm surprised to only discover it now. I can't recall the last time I
did a full test run, so I'm not sure how long it has been failing.
Jeremy
Dmitry Vasiliev has submitted a C implementation for the bisect module.
My thoughts are to accept it with the following changes:
* leave the original code intact for teaching purposes
* import the C version from _bisect
* make sure the C code is not list specific and will work with any
container supporting __len__(), __getitem__(), and insert().
Do you guys have any objections?
Raymond Hettinger
