Mailman 3 May 2002 - Python-Dev

Allowing Unicode literals even without Unicode support?
by Guido van Rossum 27 May '02

27 May '02

Many test modules fail because they use Unicode literals. It's easy enough to skip Unicode-related tests (just test for the existence of 'unicode'), but it's hard to avoid having Unicode literals in the text at all. Should we perhaps silently interpret Unicode literals as regular string literals when compiling without Unicode support? It's easy to do: *** compile.c 26 Apr 2002 01:57:19 -0000 2.242 --- compile.c 24 May 2002 18:21:29 -0000 *************** *** 1135,1147 **** #endif if (isalpha(quote) || quote == '_') { if (quote == 'u' || quote == 'U') { - #ifdef Py_USING_UNICODE quote = *++s; unicode = 1; - #else - com_error(com, PyExc_SyntaxError, - "Unicode literals not supported in this Python"); - return NULL; #endif } if (quote == 'r' || quote == 'R') { --- 1135,1143 ---- #endif if (isalpha(quote) || quote == '_') { if (quote == 'u' || quote == 'U') { quote = *++s; + #ifdef Py_USING_UNICODE unicode = 1; #endif } if (quote == 'r' || quote == 'R') { --Guido van Rossum (home page: http://www.python.org/~guido/)

4 5

Re: [Python-Dev] Python 2.3 release schedule
by Michael Hudson 26 May '02

26 May '02

Guido van Rossum <guido(a)python.org> writes: > Anything else? Writing a pymemcompat.h that people can bundle with their extensions and then use the 2.3 memory interface with all Pythons in the range 1.5.2 to 2.3. I said I'd do this once the interface is settled, so I'll try to get to it in the next week or so. It shouldn't be *that* hard... Cheers, M. -- I never disputed the Perl hacking skill of the Slashdot creators. My objections are to the editors' taste, the site's ugly visual design, and the Slashdot community's raging stupidity. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq

2 1

to string or not to string...
by David Ascher 25 May '02

25 May '02

Recent checkins mean that: E:\CVS\python\dist\src\PCbuild>python Python 2.3a0 (#29, May 24 2002, 13:47:58) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> isinstance('foo', string) True >>> import string >>> isinstance('foo', string) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: isinstance() arg 2 must be a class or type >>> I realize that there isn't a backwards compatibility problem per se, but there is something bothersome about the above, I think. I also am not to keen on having to keep "str" and "string" separate, but I don't have any better suggestion for the interface name (for that's what "string" is). Do we want string to be both the module and the interface masquerading as a type? --da [Trent gets the credit for asking the question -- I'm just the tester =)]

4 5

Re: [Python-checkins] python/dist/src/Lib types.py,1.26,1.27
by Michael Hudson 25 May '02

25 May '02

montanaro(a)sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Lib > In directory usw-pr-cvs1:/tmp/cvs-serv23491 > > Modified Files: > types.py > Log Message: > add BooleanType I thought we weren't doing this anymore...? Cheers, M. -- [3] Modem speeds being what they are, large .avi files were generally downloaded to the shell server instead[4]. [4] Where they were usually found by the technical staff, and burned to CD. -- Carlfish, asr

11 52

Style guide (PEP 8) updated
by Guido van Rossum 24 May '02

24 May '02

Barry has added (with my consent :-) some additional style guidelines to PEP 8. I welcome suggestions for more guidelines. I discourage arguing over what's already in the PEP (it's a BDFL pronouncement, not a democratic document). --Guido van Rossum (home page: http://www.python.org/~guido/)

4 6

Overwriting objects before deallocating them
by Andrew Kuchling 24 May '02

24 May '02

In the cryptography toolkit, the deallocators in the C extensions all overwrite the object's contents before deallocating it. Is this dodgy practice? Is it likely or possible that some day PyObject_Del will need to look at the contents of a non-GC-supporting object before freeing it? (Encryption or hashing objects are not containers, and it's highly unlikely they ever will be, so they'll never need to support GC traversal.) --amk Example code: static void ALGdealloc(PyObject *ptr) { int i; char *obj=(char *)ptr; /* Overwrite the contents of the object, just in case... */ for (i = 0; i < sizeof(ALGobject); i++) *(obj + i) = '\0'; PyObject_DEL(ptr); } (Note to self: use memset().)

4 10

Re: [Python-Dev] New bugtracker projec
by Michael Hudson 24 May '02

24 May '02

Neal Norwitz <neal(a)metaslash.com> writes: > Michael Hudson wrote: > > > > But of course sf doesn't have one of these, and while it's a tad > > annoying to still get all the comments on bugs that I moved out of the > > 2.2.1 category, it hasn't been a major problem yet. Though I guess if > > you can comment via email, you get more comments... > > If you click the Monitor button when viewing the bug, > this will toggle getting mail. So if you are already monitoring > the bug, it will unmonitor you. > > http://sourceforge.net/help/tracker.php?helpname=monitor Learn something every day -- I didn't know that. Still, the UI leaves something to be desired! Cheers, M. -- I'd certainly be shocked to discover a consensus. ;-) -- Aahz Maruch, comp.lang.python

1 0

Re: [Python-Dev] New bugtracker projec
by Michael Hudson 24 May '02

24 May '02

Guido van Rossum <guido(a)python.org> writes: > [David] > > As a followup to a previous message, I remembered one problem with the > > original roundup nosy-list mechanism, and that's the "adding to cc list > > by replying to a email" behavior. It's the key behind the nosy-list > > concept, and I must say that it worked great when we had a small team of > > developers (4-5) and beta users. When we scaled up to over 10 people > > and thousands of users, then that behavior was much too generous, and > > you hesitated to make a comment on a bug for fear of being attached to > > that bug forever. > > There should be a way to remove yourself. But of course sf doesn't have one of these, and while it's a tad annoying to still get all the comments on bugs that I moved out of the 2.2.1 category, it hasn't been a major problem yet. Though I guess if you can comment via email, you get more comments... Cheers, M. -- > Look I don't know. Thankyou everyone for arguing me round in > circles. No need for thanks, ma'am; that's what we're here for. -- LNR & Michael M Mason, cam.misc

3 2

Re: [Python-Dev] New bugtracker project
by Michael Hudson 24 May '02

24 May '02

Guido van Rossum <guido(a)python.org> writes: > I believe that one of the areas where we could use help is a bug > tracker. If I may so bold, I suggest the distutils could use some (paid) tender loving care, too... [...] > The point of this message is to start gathering requirements. Gordon > will gather requirements, and has asked me to send out this email to > announce the project to the Python developer community. 1) An email interface (OK, so this has been said, and already exists, but...) 2) Not having this lunatic distinction between patches and bugs or restrictions on who can add files to issues, and let people delete at least their own attachments. Cheers, M. -- SPIDER: 'Scuse me. [scuttles off] ZAPHOD: One huge spider. FORD: Polite though. -- The Hitch-Hikers Guide to the Galaxy, Episode 11

12 16

Re: [Python-Dev] New bugtracker project
by Anthony Baxter 24 May '02

24 May '02

>>> David Ascher wrote > 0) keywords -- massively useful for targeting, filtering, etc. Yes, but not in either of the standard templates. > 1) Attachments on bugs (somewhat of a merge of the patch tracker and > bug tracker, but also useful for attaching test cases, screenshots, etc.) Yes. It's also possible to add "state" to an attachment (ala bugzilla.mozilla.org). Can submit attachements via email. > 2) Being able to "watch" people - be notified when their bugs have > events happen to them, e.g.. when they're on vacation. You could install a simple reactor to say "when a nosy event happens for this user, also add that user to the nosy list." > 3) Saving and recalling searches This has been my #1 requested feature to Richard for some time. I'd ask him again, but I think he's sick of the nagging. :) > 4) non-web, non-email access to the database (e.g. take all the bugs > assigned to so and so, and take those submitted by people in england, > and set the keyword "never" to them). There's the roundupdb interface, where you can directly script the database. This requires local access (unless there's some sort of remote RPC for it). > 5) scalability (in # of developers, # of users, # of bugs, # of > 'versions', # of 'products', etc.) Unknown. > 6) Being able to migrate a bug from one product to another (not all that > relevant for a Python-only bug tracker, except if the versions are > handled as different products). Assuming we're not just talking about tweaking the metadata, this is an export/import task. Done. > 7) Bug linkages (depends on/blocks, duplicate handling, etc.) It's on the "to be done" feature list, looking for someone to do the work. > Useful things we've added to bugzilla include: > 1) Ability to designate bugs as 'for internal use only' (not especially > important for python-dev =) This is something that's being worked on at the moment. > 2) an 'efficient' UI. The bugzilla default search results pages are > very inefficient from a UI point of view. Andy McKay's version is much > better, I think. I don't see the difference in the two, aside from a smaller font? The UI for roundup's pretty much completely flexible. > As I've mentioned in the past, we used an earlier version of roundup and > found it didn't scale well with thousands of users. This was based on ping's initial prototype? The current roundup.sf.net project is a completely different thing, developed from scratch, and initially on the SC spec. > I haven't look at > the new roundup to know if it's dealt with the problems we had > (way too much mail generation by default, Ok. The way we have roundup configured is that a message is sent to a set of users when an issue is opened, and then to users that are "interested" subsequently - they've either commented on the bug, or added themselves to the nosy list. What did you find meant too much email? The "initial email out" was something we added. > much too brittle, Can't say I've seen that with the current version. > and poorly > architected =). Would need more details for this. > It's also important to have flexibility in handling the bug cycle (who > closes, who verifies, etc.). Both roundup and bugzilla did that pretty > well. Yep. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

9 10