Mailman 3 August 2004 - Python-Dev

OK to lower timeout for test_timeout's testConnectTimeout test?
by Brett Cannon Aug. 6, 2004

Aug. 6, 2004

I am actually getting failures from test_timeout's testConnectTimeout since the Net connection I have at school lets me connect to Google in under the .001 connection timeout value. If I push it to .00000001 (a hundred-millionth of a second) it then fails consistently. Now the problem is that the second part of the test uses this and a fuzz value (currently at 2) to see if the test timed out within the proper amount of time. The comparison is basically if the amount of time it took to do the timed out failure is less than timeout + fuzz. So lowering this number could possibly affect the test, although at .001 seconds, I am doubting that will occur. But since these types of timing tests can be touchy I thought I would double-check. So if anyone thinks it is bad to lower the value to .00000001 then please let me know. Otherwise I will lower the value before the next alpha goes out. -Brett P.S.: the only other failures I have on OS X right now is test_curses (because I used -uall) and test__locale . Should we disable test__locale on OS X to shut it up since Martin seems to think the test isn't all that useful and won't work for OS X ever?

6 8

Re: [Python-Dev] Re: Call for defense of @decorators
by Richie Hindle Aug. 6, 2004

Aug. 6, 2004

[Skip] > Anyone can scribble on the Wiki. You just have to be logged in. Poke the > UserPreferences link to sign up Thanks, Skip (and amk, who emailed me the same info). The page said it was immutable, and I didn't realise I could change that by logging in. I've added Shalabh's "|decorator" syntax to the wiki page at http://www.python.org/moin/PythonDecorators -- Richie Hindle richie(a)entrian.com

1 0

RE: [Python-Dev] Tuple/list assignment question
by Delaney, Timothy C (Timothy) Aug. 6, 2004

Aug. 6, 2004

Dave Cole wrote: > Is there any reason why something like this would not be a good idea? > > >>> a_list = [1, 2, 3, 4, 5] > >>> a, b, *c = a_list > > You could then do things like this: > > >>> lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] > >>> for a, b *c in lol: > ... This proposal has come up several times before (for the record, I like it). I believe there was a particular reason it's never gone forward, but I can't remember what it was. Unfortunately, it's not an easy thing to search for in the c.l.py archives :( I think it's about time this proposal got a PEP of its own ... something like "Enhanced Tuple Unpacking" (to match "Enhanced Argument Tuples" ... Tim Delaney

4 3

RE: [Python-Dev] 2.4a2, and @decorators
by Michael Chermside Aug. 6, 2004

Aug. 6, 2004

Michael Hudson writes: > > that would be insane, > > class C(random.choice([dict, list])): > pass > > is my favourite example of this :-) Where is THAT monstrocity used!? -- Michael Chermside

4 5

The impact of '@' on Leo
by Edward K. Ream Aug. 6, 2004

Aug. 6, 2004

The mandate for this post is the following from GvR: > Please bring up the Leo issues in Python-dev. The major concern I have with '@' syntax as it relates to Leo is the potential for ongoing and never-ending conflicts between Leo's directives and @x constructs in Python. Leo presently supports the following directives: @ (followed by one or more whitespace characters) @all, @asis, @c, @code, @color, @comment, @delims, @doc, @encoding, @end_raw, @file, @first, @header, @ignore, @killcolor, @language, @last, @lineending, @nocolor, @noheader, @noref, @nosent, @nowrap, @others, @pagewidth, @path, @quiet, @raw, @root, @root-code, @root-doc, @silent, @tabwidth, @terse, @thin, @unit, @verbose, @wrap Worse, Leo allows plugins to define their own directives. There is already a plugin that defines @wiki. Furthermore, @run, @test and @suite are also used in special contexts. Leo's users could probably live with a small, fixed set of @x constructs in Python. But if the Python programmer can create new @x identifiers then they have a big, big problem. What happens when another Python @x construct conflicts with one of these directives or some other directive? These directives act as a markup meta-language. Many of these directives are found interspersed in the code: a conflict with a construct in Python would have most unhappy consequences. To make matters worse, one of the _best_ choices I ever made in Leo was to remove all "escape" conventions regarding '@' (and other noweb constructs). This took a bit of courage, but it has turned out to be clearly the right choice. But if Python can now generate arbitrary @x strings Leo will have to do something really drastic. There are a number of markup languages that use '@' to from the underlying language (Python) to the markup language. I was always under the impression that the clear statement in the Reference Manual that at signs are invalid everywhere (except in comments and strings) was a clear signal of an intention to keep those symbols for other valid purposes. I do hope this won't change. Edward P.S. I recently wrote a pretty-printer for Python using the tokenize module. What will be the status of the '@' token? Is it still an "errortoken" ? Sure, this is a minor point, but it _will_ affect other tools. EKR -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

6 8

signed - unsigned - big troubles 2.4a2
by Grzegorz Makarewicz Aug. 6, 2004

Aug. 6, 2004

Many python programmas are relaying on computer int size - in prior versions bitnees is 32 long - now smoething happens and signed/unsigned value is not 32 bit long int but unsigned long int or even better unsigned uint64 consider that: a = ord(data[i]) .. data[i+4] - value is int or int64, signed or unsigned ? 0xf.. in prior versions up to 2.4.a2 int was used as signed value, now it is unsigned int64, so my question how to create signed int32 ? mak

2 2

RE: [Python-Dev] Questions about '@' in pep 318
by Moore, Paul Aug. 6, 2004

Aug. 6, 2004

From: Edward K. Ream > The "mandate" for this post is the following from GvR: > >> If good arguments against @ are presented it may be removed in >> 2.4b1 (that was always the plan but apparently not publicized). > > So I would like seriously to consider whether removing '@' might > be a good idea. > > Note: my major concern with pep 318 has always been with syntax. > I am not interested or qualified to discuss whether annotation > in general is a good idea... One point here. To get the "@" syntax removed, you will (should) need to *either* convince everyone who dislikes the "@" syntax to back a single alternative syntax (experience shows that this is unlikely in the extreme) *or* argue that the whole decorator feature be removed. You can't do the latter without discussing semantics and "whether annotation in general is a good idea". Please do not mislead people into thinking that a discussion of syntax alone is of any value, *unless* there is a willingness on the part of those against the "@" syntax to compromise on a single alternative. Semantics is a different matter - I've not heard any strong arguments against the semantics of decorators. And process is a different matter again - but that's for a different posting (which I may well not make...) Paul. __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________

1 0

trunk frozen for 2.4a2
by Anthony Baxter Aug. 6, 2004

Aug. 6, 2004

Please hold off on any checkins to the trunk for the next 24 hours or so (I'll post a followup when we're done) for 2.4a2. (The usual exception for the release team of me, Fred and Martin applies). Once the second alpha is out the door, I plan to put together a list of items that are still pending for 2.4 - any that can't find someone to do the work will have to seriously be considered at risk. At the moment, the major piece of orphaned work is the relative imports and multi-line imports. The only other piece of major unfinished work that springs to mind is the $string interpolation, but there's a bunch of other smaller pieces. I updated the release PEP after the first alpha - it's probably useful for a few folks to scan through this and see if I missed anything. Ta, Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

6 7

Re: PEP-0318
by Skip Montanaro Aug. 6, 2004

Aug. 6, 2004

Anthony> ... here's what I managed [to edit in PEP 318] before a tidal Anthony> wave of crap flowed in... I checked in Anthony's changes to PEP 318 (sent in private email) with very few modifications. I simply didn't have enough time to do more this evening. I didn't even have the time to read back through the entire document. Anybody else who feels like taking a whack at it, feel free. I'll be out of Internet reach over the weekend, so it's unlikely I'll be able to do anything more with it until next week. Context diffs against v 1.15 would be best on the off-chance I get inputs from multiple people. A SourceForge patch would be the best place to stick such things so other people can see where your changes are. Note that I'm not really interested in thirty-leven new syntax proposals. What would be helpful are pointers to other documents and concise summaries of some of the discussions on c.l.py and python-dev. Incorporation of all or part of http://www.python.org/moin/PythonDecorators into the PEP would also be appreciated. Try to write objectively. A PEP isn't Usenet. <wink> Note how I'm being optimistic that multiple people will contribute. Lots of people have worn out their keyboards on this subject, so I know the energy is out there. It just needs to be focused a bit. Thx, Skip

1 0

RE: [Python-Dev] Re: Call for defense of @decorators
by Delaney, Timothy C (Timothy) Aug. 6, 2004

Aug. 6, 2004

Shalabh Chaturvedi wrote: > |paramnames(username='Username', password='Password') > |webmethod(username=str, password=str) > def login(self, username, password, return_to=None): > request = current.request > ... > > |webmethod() > def logout(self, return_to=None): > current.request.session.user = None > return current.request.redirect(return_to or self._q_location) > > Appears accentuated, yet clean, specially for simple/single > decorators. > Gives an appearance that the decorators are 'connected' to the > function. This looks remarkably nice to me for a syntax before the definition. Astoundingly so. I still prefer list-before-colon, but the above would alleviate much of my distate for @ which is that it doesn't look as though the decorators are connected to the definition. Hmm - perhaps a further variation ... |paramnames(username='Username', password='Password') | |webmethod(username=str, password=str) | def login(self, username, password, return_to=None): request = current.request i.e. the decorators must be connected to the def, but you can use some whitespace to make them look better (for decorators with long parameter lists). Would be hell to parse though ... Tim Delaney

2 1