Python-Dev December 2003

python-dev@python.org

129 participants
207 discussions

RE: [Python-Dev] Those import related syntax errors again...

by Samuele Pedroni

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.

15 years, 4 months

Can we please have a better dict interpolation syntax?

by Greg Ewing

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 +--------------------------------------+

15 years, 12 months

Does anybody really use frame->f_tstate ?

by Christian Tismer

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/

16 years, 3 months

RELEASED Python 2.3.3 (release candidate 1)

by Anthony Baxter

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)

16 years, 3 months

Re: [Python-Dev] Pie-thon benchmark code ready

by Guido van Rossum

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/)

16 years, 5 months

Switching to VC.NET 2003

by Martin v. Loewis

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

16 years, 5 months

PEP0004: audioop deprecated?

by Anthony Baxter

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

16 years, 5 months

Fixes for imageop module

by Sjoerd Mullender

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>

16 years, 6 months

test_unicode_file fails on Linux

by Jeremy Hylton

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

16 years, 6 months

SF patch 864863: Bisect C implementation

by Raymond Hettinger

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

16 years, 6 months

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev December 2003