Python-Dev June 2003

python-dev@python.org

118 participants
144 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, 9 months

2.3b1 release

by Guido van Rossum

I'd like to do a 2.3b1 release someday. Maybe at the end of next week, that would be Friday April 25. If anyone has something that needs to be done before this release go out, please let me know! Assigning a SF bug or patch to me and setting the priority to 7 is a good way to get my attention. --Guido van Rossum (home page: http://www.python.org/~guido/)

17 years, 3 months

PEP-317

by Raymond Hettinger

I'm +0 on finally deprecating the string exceptions. But am -1000 on eliminating implicit instantiation before Py3.0. Right after writing: "In short, implicit instantiation has no advantages other than backwards compatibility ..." I think it would only be fair to add: "If this proposal is adopted, nearly every piece of non-trivial python code that has ever been written would need to be revised or would fail to run. Likewise, most tutorial and book examples would also fail." Raymond Hettinger

17 years, 4 months

Can't compile _tkinter.c with Redhat 9 (post-SF#719880)

by Gerrit Holl

Hi, I am unable to compile Python 2.3 + _tkinter (latest CVS) with Redhat 9. Earlier suggestions on python-dev and SF won't help or arise other problems. The _tkinter module won't be compiled: I get the following error messages when I do nothing: Modules/_tkinter.c:96:2: #error "unsupported Tcl configuration" Modules/_tkinter.c: In function `AsObj': Modules/_tkinter.c:947: warning: passing arg 1 of `Tcl_NewUnicodeObj' from incompatible pointer type Modules/_tkinter.c: In function `FromObj': Modules/_tkinter.c:1073: warning: passing arg 1 of `PyUnicodeUCS2_FromUnicode' from incompatible pointer type About same problem was arised in this message: http://mail.python.org/pipermail/python-dev/2003-April/034724.html And in SF#719880. But there are some differences. This is after SF#719880 has been applied. When I remove the test, I do *not* get a working version of Tkinter: $ ./python Python 2.3b1+ (#1, Jun 12 2003, 22:15:45) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. 0 >>> import Tkinter 1 >>> Tkinter._test() Segmentation fault Later in the thread, the suggestion was made to compile with --enable-unicode=ucs4. However, then I get: *** WARNING: renaming "array" since importing it failed: build/lib.linux-i686-2.3/array.so: undefined symbol: PyUnicodeUCS2_FromUnicode *** WARNING: renaming "_testcapi" since importing it failed: build/lib.linux-i686-2.3/_testcapi.so: undefined symbol: PyUnicodeUCS2_Decode *** WARNING: renaming "unicodedata" since importing it failed: build/lib.linux-i686-2.3/unicodedata.so: undefined symbol: PyUnicodeUCS2_FromUnicode *** WARNING: renaming "_locale" since importing it failed: build/lib.linux-i686-2.3/_locale.so: undefined symbol: PyUnicodeUCS2_AsWideChar *** WARNING: renaming "cPickle" since importing it failed: build/lib.linux-i686-2.3/cPickle.so: undefined symbol: PyUnicodeUCS2_AsUTF8String *** WARNING: renaming "pyexpat" since importing it failed: build/lib.linux-i686-2.3/pyexpat.so: undefined symbol: PyUnicodeUCS2_DecodeUTF8 Tkinter now works, but array, locale, cPickle, etc. are not present. How can I solve this problem? Is it a bug? Or is it something on my system? Gerrit. -- 234. If a shipbuilder build a boat of sixty gur for a man, he shall pay him a fee of two shekels in money. -- 1780 BC, Hammurabi, Code of Law -- Asperger Syndroom - een persoonlijke benadering: http://people.nl.linux.org/~gerrit/ Het zijn tijden om je zelf met politiek te bemoeien: http://www.sp.nl/

17 years, 4 months

release candidate rules and timeit API question

by Brett C.

OK, now that I have Internet again I can try to get some Python work done and commit what work I was able to do while I was disconnected. But I noticed that we are now working on a release candidate. Are the commit rules any different than for a beta? I specifically want to commit a patch to make using _strptime for time.strptime permanent by ditching the #ifdef code and flesh out the docs. My timeit API question has to do with timeit.default_timer . The docs don't mention it but I think it might be nice to expose it. The specific I would like to have it available for guaranteed use is that both 'threading' and Queue have code that sleep on an ever-increasing interval. They both use time.time for their time measurements which is fine on UNIX but sucks on Windows when you consider the max time both chunks of code wait is .05 secs which is below the accuracy threshold for Windows (according to Tim's intro in the Cookbook; thank god for books when tech goes kapoot). I would like to edit the code so that it uses what timeit.default_timer is set to. Anyone (especially Guido since he is timeit's original author) have a problem with documenting timeit.default_timer? -Brett

17 years, 4 months

Problem with 2.3b2 tarfile?

by Skip Montanaro

Was the 2.3b2 tarfile generated in such a way that it requires GNU tar? I'm unable to extract it on a Solaris 8 system using /usr/bin/tar. It gunzips fine and I can extract it on my Mac OS X system, but on Solaris I get, "tar: directory checksum error" and fine a truncated directory tree. I've also verified that the files downloaded to the Mac and the Solaris box have the same checksum. Skip

17 years, 4 months

cookie support for FancyURLopener?

by randy.gamage＠modicon.com

Hello, I have never contributed to the python source, but I am considering adding cookie support to the FancyURLopener library, especially in the case of a redirect, in which a cookie is issued with the 302 message, and this cookie is required to access the new page. I thought I would check if this is in progress, or if there are objections to this idea, before spending any time on it. Thanks for your input, Randy

17 years, 4 months

test_strptime failed

by Jeremy Hylton

I've been running the python tests frequently today, from a checkout I did mid-morning. I just noticed an unexpected failure. This is with a regular build; I'll see if it is repeatable. Jeremy test test_strptime failed -- Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/test/test_strptime.py", line 203, in test_compile self.failUnless(found, "Matching failed on '%s' using '%s' regex" % File "/home/jeremy/src/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: Matching failed on 'Thu 05 Jun 2003 05:46:43 PM EDT' using '(?P<a>Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s*(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P<b>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s*(?P<Y>\d\d\d\d)\s*(?P<I>1[0-2]|0[1-9]|[1-9]):(?P<M>[0-5]\d|\d):(?P<S>6[0-1]|[0-5]\d|\d)\s*(?P<p>AM|PM)\s*EST' regex

17 years, 4 months

RELEASED: Python 2.3b2

by Barry Warsaw

Python 2.3b2 is the second beta release of Python 2.3. There have be a slew of fixes since the first beta, and a few new "features". Our goal is to have a final Python 2.3 release by early August, so we encourage lots of testing for this beta. Highlights since beta 1 include: - IDLEfork has been merged in and now replaces the old IDLE. - The Windows installer now ships with Tcl/Tk 8.4.3. - list.index() has grown optional `start' and `end' arguments. - A new C-only API function PyThreadState_SetAsyncExc() which can be used to interrupt threads by sending them exceptions. - Python programs can enter the interactive prompt at program exit by setting the PYTHONINSPECT environment variable. - Many new doctest improvements, including the ability to write doctest based unit tests. - New and improved documentation for writing new types in C that participate in cyclic garbage collection. There is at least one known bug: we have seen crashes on both Windows and Linux with certain interactions between test_logging and test_bsddb3. We intend to fix this for the next release. For more highlights, see http://www.python.org/2.3/highlights.html Other new stuff since Python 2.2: - Many new and improved library modules, e.g. sets, heapq, datetime, textwrap, optparse, logging, bsddb, bz2, tarfile, ossaudiodev, and a new random number generator based on the highly acclaimed Mersenne Twister algorithm (with a period of 2**19937-1!). - New builtin enumerate(): an iterator yielding (index, item) pairs. - Extended slices, e.g. "hello"[::-1] returns "olleh". - Universal newlines mode for reading files (converts \r, \n and \r\n all into \n). - Source code encoding declarations. (PEP 263) - Import from zip files. (PEP 273 and PEP 302) - FutureWarning issued for "unsigned" operations on ints. (PEP 237) - Faster list.sort() is now stable. - Unicode filenames on Windows. - Karatsuba long multiplication (running time O(N**1.58) instead of O(N**2)). If you have an important Python application, we strongly recommend that you try it out with a beta release and report any incompatibilities or other problems you may encounter, so that they can be fixed before the final release. To report problems, use the SourceForge bug tracker: http://sourceforge.net/tracker/?group_id=5470&atid=105470 Enjoy, -Barry

17 years, 4 months

2.3b2 known bugs?

by Neal Norwitz

These are listed as known bugs in beta2 (pydotorg/2.3/bugs.ht), but I think they are solved: * On Solaris 8, build of the bz2 module failed for one correspondent; this may depend on the specific release or provisioning of the box. * The test for the logging module fails for some people on Solaris and Mac OS X. A patch has been applied to CVS that hopefully fixes this. Skip, I think you had both of these problems. Is everything ok for you? Neal

17 years, 4 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 June 2003