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