Sandbox::https://mail.python.org/archives/list/python-dev@python.org/2001/12/

RE: [Python-Dev] Those import related syntax errors again...
by Samuele Pedroni Feb. 23, 2005

Feb. 23, 2005

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.

18 78

Re: [XML-SIG] printing Unicode xml to StringIO
by Martin v. Loewis Jan. 6, 2002

Jan. 6, 2002

[Over to python-dev. Jaco noticed that writing Unicode objects to a StringIO object stopped working in 2.2, see http://mail.python.org/pipermail/xml-sig/2001-December/006891.html ] Marc-Andre writes > Actually, I think that this is a bug in the documentation, not the > code. StringIO and cStringIO were never meant to work on anything but > strings and memory buffers. IMO, "strings" should include both byte strings and Unicode strings. Mixing them may not be allowed, but that is a different story. In fact, there is an open bug (#216388) that cStringIO rejects Unicode objects. If that gets fixed, we get the funny scenario that StringIO rejects Unicode object, whereas cStringIO accepts them. > The note that Fred added to the docs about StringIO's capability of > storing Unicode in it's buffer list is simply an artifact of the > implementation. There are many developers who take this note literally. Claiming that this was not intentional is a mistake. > Please use the .encode() method on Unicode objects before writing > them to a StringIO object. If you want to end up with a byte string, this is a good idea. But I think it is pointless to require encoding them when you want to end up with a Unicode string; you'd have to invoke unicode() on the result, for no apparent reason but a bug in the StringIO implementation. Regards, Martin

3 8

Offline for a while
by Jack Jansen Dec. 31, 2001

Dec. 31, 2001

Folks, I will probably be unreacable by mail for the next few days, the backup we put in for our move seems to be non-functional. So don't worry about bounceds to the oratrix.nl address, all should be well again on wednseday or thusrday (and backspace also doesn't work on this machine:-) Jack

1 0

[development doc updates]
by Fred L. Drake Dec. 28, 2001

Dec. 28, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ A variety of updates made since Python 2.2 was released.

1 0

[development doc updates]
by Fred L. Drake Dec. 28, 2001

Dec. 28, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/maint-docs/ The "maintenance version" of the Python documentation on the Python development site at SourceForge has been updated to show the docs being developed for Python 2.2.1.

1 0

Documentation for Python 2.2.1
by Fred L. Drake, Jr. Dec. 28, 2001

Dec. 28, 2001

I've brought the docs in Python's release22-maint branch up to date with the corrections that have been made on the trunk. I'll be checking in relevant additions to this branch as well as the trunk when I make the trunk changes. When anyone else makes a change on the trunk which should also be made on the 2.2 maintenance branch, feel free to check it in in both places, or add a note to the checkin message noting that it should be made on the branch as well, and I'll try to make sure that gets done. The 2.2 maintenance branch has replaced the 2.1 maintenance branch as the "maintenance version" at http://python.sourceforge.net/; if anyone thinks we should continue to offer the 2.1 maintenance docs there, please let me know. I don't think we have a Patch Czar for 2.2.1 yet; if anyone would like to take that duty for the documentation tree, I'd certainly appreciate the help! Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

Re: [Python-Dev] Python 2.2.1
by Jack Jansen Dec. 26, 2001

Dec. 26, 2001

Recently, "Fred L. Drake, Jr." <fdrake(a)acm.org> said: > > Has anything been done to get the release22-maint branch to see the > changes made for MacPython yet? We should do this before we lose > track of it. > Jack, any preference for how this is done, or did you already do it? They haven\t been checked in yet. There was a snag in the Mac distriubution that has just been solved, the checkins will follow shortly. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Python-Dev] Python 2.2.1
by Anthony Baxter Dec. 26, 2001

Dec. 26, 2001

>>> Jack Jansen wrote > - The final bits of the Mac tree havne't been checked in yet, should > we move the release22-maint branch when that's done? Can you move a > branch? How? D'oh! Hm, I'm not sure how easily that can be done. In theory you should be able to "cvs tag -d release22-maint" in the Mac-specific subdirectory, then do the checkins, then "cvs tag -b release22-maint" in the Mac directory again. So long as there's not been any checkins on the branch in the directories that you're doing the tag shifting, you should be fine. Probably. Although checking on a little toy CVS root is probably a great idea :) In fact, I just did this on a local toy project, and it worked fine. I'd strongly recommend using cvs tag -d followed by retagging, rather than using tag -F to try and move it - I've had bad experiences in the past with -F -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1

Re: [Python-Dev] Python 2.2.1
by Jack Jansen Dec. 25, 2001

Dec. 25, 2001

Two questions wrt 2.2.1: - Is there a timeline for it? I couldn't find one in PEP251 (which stops at 2.2 final). The reason I ask is that there's a serious flaw in MacPython (has been there since day one) that renders it useless on multiprocessor Mac OS X machines. I'm waiting for an external party to fix this (as the problem is in an external library), but I could put a bit of pressure on if 2.2.1 is due reasonably soon (as I hope). - The final bits of the Mac tree havne't been checked in yet, should we move the release22-maint branch when that's done? Can you move a branch? How? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

4 4

Re: [Python-Dev] Python 2.2.1
by Anthony Baxter Dec. 23, 2001

Dec. 23, 2001

>>> Michael Hudson wrote > I've just spent half an hour fiddling with gnus to the point that it > should be easy for me to keep a log of checkins that should be put on > the release22-maint branch. > > This isn't me volunteering to be Patch Czar, by the way... I don't > know if I'll have time for that, but I hope that doing this will help > whoever it ends up being. I'm happy enough to continue doing this - now that it's starting from a caught-up position, it's not that hard. The problem with 2.1.2 was trawling back through 6 months of checkins... Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Python-Dev

December 2001