Re: [Python-Dev] The docs, reloaded

On Tue, 22 May 2007, Steve Holden wrote: > But doesn't *everyone* now know that documentation contributions don't > have to be marked up? It's certainly been said enough. Maybe that fact > should be more prominent in the documentation? Then we'll just have to > worry about getting people to read it

Re: [Python-Dev] The docs, reloaded

On Sat, 19 May 2007, Georg Brandl wrote: > For the impatient: the result can be seen at . This is extremely impressive. Thank you for this work! If all the documentation is generated from a base format that is closer to text (reST instead of LaTeX), that will make it eas

Re: [Python-Dev] PEP 30XZ: Simplified Parsing

I fully support the removal of implicit string concatenation (explicit is better than implicit; there's only one way to do it). I also fully support the removal of backslashes for line continuation of statements (same reasons). (I mean this as distinct from line continuation within a string; that

Re: [Python-Dev] datetime module enhancements

On Sat, 10 Mar 2007, Greg Ewing wrote: > Collin Winter wrote: > > Treat dates as if they have a time-part of midnight. This is my preferred > > solution, and it is already what the datetime module does, for example, > > when subtracting two dates. > > Does it really? Seems to me you can pick any ti

Re: [Python-Dev] Pydoc Improvements / Rewrite

On Thu, 4 Jan 2007, Talin wrote: > One issue that needs to be worked out, however, is the division of > responsibility between markup processor and output formatter. Does a > __markup__ plugin do both jobs, or does it just do parsing, and leave > the formatting of output to the appropriate HTML / t

Re: [Python-Dev] Pydoc Improvements / Rewrite

Hi Ron and Laurent, I welcome attempts to improve pydoc (especially since I don't have much time to work on improving it myself). I definitely agree that moving to CSS is long overdue, though I would like some input on the style of the produced pages. It's probably a good idea to explain how pyd

Re: [Python-Dev] a feature i'd like to see in python #2: indexing of match objects

On Sun, 3 Dec 2006, Fredrik Lundh wrote: > Martin v. Löwis wrote: > > Well, the proposal was to interpret m[i] as m.group(i), for all values > > of i. I can't see anything confusing with that. > > it can quickly become rather confusing if you also interpret m[:] as > m.groups(), not to mention if y

[Python-Dev] Python in first-year MIT core curriculum

Wow. Did you catch this news? http://www-tech.mit.edu/V125/N65/coursevi.html The first four weeks of C1 will be a lot like the first four weeks of 6.001, Abelson said. The difference is that programming will be done in Python and not Scheme. -- ?!ng ___

Re: [Python-Dev] Importing .pyc in -O mode and vice versa

On Mon, 6 Nov 2006, Armin Rigo wrote: > I know it's a discussion that comes up and dies out regularly. My two > cents is that it would be saner to have two separate concepts: cache > files used internally by the interpreter for speed reasons only, and > bytecode files that can be shipped and impor

Re: [Python-Dev] new security doc using object-capabilities

Hi Brett, Here are some comments on your proposal. Sorry this took so long. I apologize if any of these comments are out of date (but also look forward to your answers to some of the questions, as they'll help me understand some more of the details of your proposal). Thanks! > Introduction > //

Re: [Python-Dev] uuid module - byte order issue

On Fri, 4 Aug 2006, Oren Tirosh wrote: > Compatibility with Windows "GUIDs" may be one of the most important > use cases for the UUID module. It's important to resolve this or users > will have unpleasant surprises. I did. [...] > alternatives: > > 1. Default is big endian byte order. Little endia

Re: [Python-Dev] uuid module - byte order issue

yte first (known as network byte order). > Ka-Ping Yee writes* that the Windows UUID generation calls are not RFC > 4122 compliant and have an illegal version field. [...] > If the correct byte order is used the UUIDs generated by Windows XP > are valid version 4 UUIDs: I see

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

On Thu, 3 Aug 2006, Greg Ewing wrote: > The time isn't the main issue. The main issue > is that almost all the use cases for round() > involve doing an int() on it afterwards. That's my experience as well. In my opinion, the purpose of round() is most commonly described as "to make an integer".

Re: [Python-Dev] test_uuid

On Sat, 29 Jul 2006, Neal Norwitz wrote: > I just checked in a change to disable testing 2 uuid functions > (_ifconfig_get_node and unixdll_getnode) that fail on many platforms. > Here's the message: > > """ > Disable these tests until they are reliable across platforms. These > problems may mask m

Re: [Python-Dev] uuid test suite failing

On Fri, 28 Jul 2006, Neal Norwitz wrote: > This only fixes 1 of the 2 failures in test_uuid. The other one is > due to _unixdll_getnode() failing. This is because > _uuid_generate_time is None because we couldn't find it in the uuid > library. This is just broken, not sure if it's the code or th

Re: [Python-Dev] new security doc using object-capabilities

On Wed, 19 Jul 2006, Brett Cannon wrote: > I have decided to go with object-capabilities for > securing interpreters. I have rewritten my design doc from scratch and > deleted the old one. The new doc is named securing_python.txt and can be > found through the svn web interface at > http://svn.py

Re: [Python-Dev] Handling of sys.args (Re: User's complaints)

On Thu, 13 Jul 2006, Greg Ewing wrote: > Would it help if sys were pre-imported into the builtins? > Or do you think that args shouldn't live in sys at all? I feel like the command-line arguments don't really belong in sys, and i'd rather not have 'sys' pre-imported into the builtins. I think of

Re: [Python-Dev] User's complaints

On Thu, 13 Jul 2006, Wolfgang Langner wrote: > On 7/13/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > > Things that struck me as peculiar is the old: > > > > if __name__ == "__main__": > > whatever() > > > > This is so out of tune with the rest of python it becomes a nuisance. >

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

On Thu, 13 Jul 2006, Fredrik Lundh wrote: > Boris Borcic wrote: > > >> note that most examples of this type already work, if the target type is > >> mutable, and implement the right operations: > >> > >> def counter(num): > >> num = mutable_int(num) > >> def inc(): > >>

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

On Mon, 10 Jul 2006, Jeremy Hylton wrote: > The current use of global meets the requirements. The meaning there > is clear, because global means global namespace. If purple were a > keyword, I wouldn't know what it means. I was not proposing the use > of global for some other meaning (and though

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

On 7/10/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > What's wrong with "nonlocal"? I don't think i've seen an argument > against that one so far (from Talin or others). On Mon, 10 Jul 2006, Jeremy Hylton wrote: > It's a made-up word. You won't

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote: > I think Talin's got a point though. It seems hard to find one short English > word that captures the essence of the desired behavior. None of the words > in his list seem strongly suggestive of the meaning to me. I suspect that > means one's ultimat

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

On Sun, 9 Jul 2006, Andrew Koenig wrote: > > Sounds reasonable to me. If we're talking py3k I'd chuck "global" as a > > keyword though and replace it with something like "outer". > > I must say that I don't like "outer" any more than I like "global." The > problem is that in both cases we are sel

Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

On Fri, 7 Jul 2006, Talin wrote: > While I was typing this, I did realize a drawback to poisoned objects, > which I will illustrate by the following example: > > Suppose we want to grant to the sandboxed program permission to read and > write cofiguration properties. We don't want to give them arbi

Re: [Python-Dev] Musings on concurrency and scoping ("replacing" Javascript)

On Fri, 7 Jul 2006, Guido van Rossum wrote: > On 7/7/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > > I've been doing a bunch of Firefox extension programming in Javascript > > and suddenly a few of the recent topics here came together in my head > > in a silent kapow

Re: [Python-Dev] Musings on concurrency and scoping ("replacing" Javascript)

On Thu, 6 Jul 2006, Phillip J. Eby wrote: > As much as I'd love to have the nested scope feature, I think it's only > right to point out that the above can be rewritten as something like this > in Python 2.5: > > def spam(): > local_A = do_work() > result_1 = yield do_network

[Python-Dev] Musings on concurrency and scoping ("replacing" Javascript)

On Wed, 21 Jun 2006, Brett Cannon wrote: > I have been working on a design doc for restricted execution of Python > as part of my dissertation for getting Python into Firefox to replace > JavaScript on the web. I've been doing a bunch of Firefox extension programming in Javascript and suddenly a f

[Python-Dev] Restricted execution: what's the threat model?

After reading the messages on this thread i'm starting to think that it would be good to clarify what kinds of threats we are trying to defend against, and specify what invariants we are intending to preserve. For example, here are a few things Brett mentioned: > Right. I am thinking more of an

Re: [Python-Dev] doc for new restricted execution design for Python

On Wed, 5 Jul 2006, Brett Cannon wrote: > On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > > In response to Guido's comment about confusing the words "trusted" and > > "untrusted", how about "empowered" and "restricted"? >

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

On Wed, 5 Jul 2006, Guido van Rossum wrote: > On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > Using the classic nonsense example: > > > > def counter(num): > > def inc(): > > .num += 1 > > return .num > > return inc > > > Would this also use

Re: [Python-Dev] doc for new restricted execution design for Python

Hi Brett, Here are some comments on the description of the restricted execution model that you posted. > When referring to the state of an interpreter, it is either "trusted" or > "untrusted". A trusted interpreter has no restrictions imposed upon any > resource. An untrusted interpreter has at

Re: [Python-Dev] Lexical scoping in Python 3k

On Sat, 1 Jul 2006, Andrew Koenig wrote: > I'd rather see a simpler rule: = never defines a variable in a surrounding > scope. If you want to affect the binding of such a variable, you have to > define it explicitly in the scope in which you want it. > > Example: > > x = 42 > def f():

Re: [Python-Dev] Lexical scoping in Python 3k

On Sat, 1 Jul 2006, Greg Ewing wrote: > I don't disagree with anything you said, but I think it > would be a good idea to avoid using phrases like "proper > lexical scopes", which is likely to set people off on > a tangent. The issue isn't lexicality, it's writeability. "Fully functional" lexical

Re: [Python-Dev] 2.5 and beyond

On Fri, 30 Jun 2006, Andrew Koenig wrote: > The fundamental principle is that the binding of every name is determined > during compilation, not during execution. This property does not quite > apply to Python at present. I think this property does apply. In your example: > def g(): >

[Python-Dev] Lexical scoping in Python 3k

On Fri, 30 Jun 2006, Guido van Rossum wrote: > On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > > On Fri, 30 Jun 2006, Andrew Koenig wrote: > > > I hope Py3000 has lexical scoping a la Scheme... > > > > Me too -- that would be really nice. > &g

Re: [Python-Dev] For sandboxing: alternative to crippling file()

On Fri, 30 Jun 2006, Brett Cannon wrote: > On 6/30/06, Armin Rigo <[EMAIL PROTECTED]> wrote: > > >>> object.__subclasses__() > > [..., ] > > > > Maybe this one won't work if __subclasses__ is forbidden, but in general > > I think there *will* be a way to find this object. > > Yeah, that's b

Re: [Python-Dev] 2.5 and beyond

On Fri, 30 Jun 2006, Andrew Koenig wrote: > I saw messages out of sequence and did not realize that this would be a > change in behavior from 2.4. Sigh. Yes, this is not a good time to change it. > I hope Py3000 has lexical scoping a la Scheme... Me too -- that would be really nice. -- ?!ng _

Re: [Python-Dev] 2.5 and beyond

On Fri, 30 Jun 2006, Neal Norwitz wrote: > The current list of serious bugs are in the PEP: > > http://www.python.org/dev/peps/pep-0356/ Among them is this one: Incorrect LOAD/STORE_GLOBAL generation http://python.org/sf/1501934 The question is, what behaviour is preferable for this co

Re: [Python-Dev] Switch statement - handling errors

On Tue, 27 Jun 2006, Jim Jewett wrote: > (Almost) everyone agrees that the case expressions SHOULD be run-time > constants. The disagreements are largely over what to do when this > gets violated. I like your summary and understood most of it (options 1, 2, 3, 5, 6). The only part i didn't unders

Re: [Python-Dev] doc for new restricted execution design for Python

Hi, Brett. > I have been working on a design doc for restricted execution of Python I'm excited to see that you're working on this. > as part of my dissertation for getting Python into Firefox to replace > JavaScript on the web. Wow. What's your game plan? Do you have a story for convincing t

[Python-Dev] School IIb?

Here's a possible adjustment to the School-II approach that i think avoids the issues i've been raising, while giving the desired O(n)-to-O(1) speedup in common situations. It's basically School-II dispatch, plus a check: On compilation, freeze any cases that meet the School-II conditions and hav

Re: [Python-Dev] PEP 3103: A Switch/Case Statement

On Mon, 26 Jun 2006, Guido van Rossum wrote: > Most school I proponents (perhaps you're the only exception) have > claimed that optimization is desirable, but added that it would be > easy to add hash-based optimization. IMO it's not so easy in the light > of various failure modes of hash(). (A pos

Re: [Python-Dev] PEP 3103: A Switch/Case Statement

On Mon, 26 Jun 2006, Guido van Rossum wrote: > Can you please edit the PEP yourself to add this? That will be most efficient. I've done so, and tried to clarify the next line to match (see below). > With school I, if you want to > optimize using a hash table (as in PEP 275 Solution 1) you have to

Re: [Python-Dev] PEP 3103: A Switch/Case Statement

On Mon, 26 Jun 2006, Guido van Rossum wrote: > I've written a new PEP, summarizing (my reaction to) the recent > discussion on adding a switch statement. While I have my preferences, > I'm trying to do various alternatives justice in the descriptions. Thanks for writing this up! The section that

Re: [Python-Dev] Simple Switch statementZ

On Sun, 25 Jun 2006, Guido van Rossum wrote: > What do you think of Nick C's 'once'? It's a bit closer to the right meaning... but what about: def f(x): def g(y): return y + once x return g Does "once" mean not really once here, but "once for each new function obj

Re: [Python-Dev] Simple Switch statementZ

On Mon, 26 Jun 2006, Georg Brandl wrote: > Raymond Hettinger wrote: > >five = 5 > >eight = [8] > >def f(x, six=6): > > seven = 7 > > a = static(five + 4)# this is legal > > b = static(six + 4) # this is illegal > > c = static(seven + 4)

Re: [Python-Dev] Simple Switch statement

On Sun, 25 Jun 2006, Guido van Rossum wrote: > In your eagerness to > rule out surprises, you're creating the biggest surprise of all: the > restriction to literals is certainly a surprise! I disagree. Perhaps what we mean by "surprise" is different. In Raymond's design, there is a simple rule f

Re: [Python-Dev] Simple Switch statement

On Sat, 24 Jun 2006, Phillip J. Eby wrote: > At 03:49 PM 6/24/2006 -0700, Raymond Hettinger wrote: > >Cases values must be ints, strings, or tuples of ints or strings. > > -1. There is no reason to restrict the types in this fashion. Even if you > were trying to ensure marshallability, you could

Re: [Python-Dev] Simple Switch statement

On Sat, 24 Jun 2006, Raymond Hettinger wrote: > The main points of contention are 1) a non-ambiguous syntax for assigning > multiple cases to a single block of code, 2) how to compile variables as > constants in a case statement, and 3) handling overlapping cases. > > Here's a simple approach that

Re: [Python-Dev] Switch statement

On Fri, 23 Jun 2006, Josiah Carlson wrote: > This is a good thing, because if switch/case ends up functionally > identical to if/elif/else, then it has no purpose as a construct. This doesn't make sense as a rule. Consider: "If x.y ends up functionally identical to getattr(x, 'y'), then

Re: [Python-Dev] Switch statement

On Wed, 21 Jun 2006, Guido van Rossum wrote: > (Note how I've switched to the switch-for-efficiency camp, since it > seems better to have clear semantics and a clear reason for the syntax > to be different from if/elif chains.) I don't think switch-for-efficiency (at least if efficiency is the pri

Re: [Python-Dev] Switch statement

On Wed, 21 Jun 2006, Guido van Rossum wrote: > I worry (a bit) about this case: > > y = 12 > def foo(x, y): > switch x: > case y: print "something" > > which to the untrained observer (I care about untrained readers much > more than about untrained writers!) looks like it would print >

Re: [Python-Dev] Switch statement

On Wed, 21 Jun 2006, Phillip J. Eby wrote: > Well, EIBTI and all that: > > switch x: > case == 1: foo(x) > case in S: bar(x) > > It even lines up nicely. :) Hmm, this is rather nice. I can imagine possible use cases for switch x: case > 3: foo(x) case

Re: [Python-Dev] Switch statement

On Mon, 19 Jun 2006, Josiah Carlson wrote: > I personally don't find switch/case statements to be significantly (if > at all) easier to read than if/elif/else chains, but that is subjective, > and I note that Ka-Ping finds switch/case to be significantly easier to > read. Uh, i didn't mean to say

Re: [Python-Dev] uuid backward compatibility

On Mon, 19 Jun 2006, Guido van Rossum wrote: > If you want to encourage people to use your module > with older versions, the right path is to have a distribution (can be > very light-weight) on your own website and add it to PyPI Okay, i've removed the comment and submitted the package to PyPI.

Re: [Python-Dev] uuid backward compatibility

On 6/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > As for the comment: It apparently *is* misleading, George mistakenly > took it as a requirement for future changes, rather than a factual > statement about the present (even though it uses the tense of simple > present). Anybody breaking 2

Re: [Python-Dev] Switch statement

On Mon, 19 Jun 2006, Guido van Rossum wrote: > Um, is this dogma? Wouldn't a switch statement also be a welcome > addition to the readability? I haven't had the time to follow this > thread (still catching up on my Google 50%) but I'm not sure I agree > with the idea that a switch should only exist

Re: [Python-Dev] uuid backward compatibility

On Sun, 18 Jun 2006, George Yoshida wrote: > uuid.py says in its docstring: > This module works with Python 2.3 or higher. > > And my question is: > Do we plan to make it 2.3 compatible in future releases? > > If so, uuid needs to be listed in PEP 291. > Otherwise, the comment is misleading. T

Re: [Python-Dev] UUID module

On Mon, 12 Jun 2006, Giovanni Bajo wrote: > GetSystemDirectory() is the official way to find the system directory. You're right. I've added a call to GetSystemDirectory, with a fallback to the usual locations if it doesn't work. > Another thing that you might do is to drop those absolute system

Re: [Python-Dev] UUID module

On Sun, 11 Jun 2006, Phillip J. Eby wrote: > At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote: > >I've added code to make uuid1() use uuid_generate_time() if available > >and uuid4() use uuid_generate_random() if available. These functions > >are provided on Mac OS X

Re: [Python-Dev] UUID module

On Sun, 11 Jun 2006, Giovanni Bajo wrote: > Some comments on the code: > > > for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']: > > Can we get rid of these absolute paths? Something like this should suffice: > > >>> from ctypes import * > >>> buf = create_string_buffer(4096) > >>> windl

[Python-Dev] Should hex() yield 'L' suffix for long numbers?

I did this earlier: >>> hex(9) '0x9184e729fffL' and found it a little jarring, because i feel there's been a general trend toward getting rid of the 'L' suffix in Python. Literal long integers don't need an L anymore; they're automatically made into longs if the number is too

Re: [Python-Dev] UUID module

Thomas Heller wrote: > I don't know if this is the uuidgen you're talking about, but > on linux there is libuuid: Thanks! Okay, that's in there now. Have a look at http://zesty.ca/python/uuid.py . Phillip J. Eby wrote: > By the way, I'd love to see a uuid.uuid() constructor that simply calls th

Re: [Python-Dev] UUID module

On Sat, 10 Jun 2006, Thomas Heller wrote: > [some nice ctypes code] Done. Works like a charm. Thanks for providing the code! On Sat, 10 Jun 2006, Phillip J. Eby wrote: > Also, for Python 2.5, these imports could probably be replaced with a > ctypes call, though I'm not experienced enough w/ctyp

Re: [Python-Dev] beta1 coming real soon

On Sat, 10 Jun 2006, Paul Moore wrote: > Actually, the code uses "ifconfig", which doesn't exist on Windows. > You want the command "ipconfig /all". I fixed that before you posted this message. :) -- ?!ng ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] UUID module

On Sat, 10 Jun 2006, Thomas Heller wrote: > I have not tested the speed, but extending my snippet to also work > on 98 should be nearly trivial: > > try: > _func = windll.rpcrt4.UuidCreateSequential > except AttributeError: > _func = windll.rpcrt4.UuidCreate > > def CreateGuid(): > uuid

Re: [Python-Dev] UUID module

Hi Thomas, > This does not work, for several reasons. > > 1. (pythoncom|pywintypes).CreateGuid() return a PyIID instance, which you > cannot slice: You're right. The PEAK code must have been based on an earlier version of the CreateGuid() routine. I've fixed this, and added detection of the UU

Re: [Python-Dev] beta1 coming real soon

On Thu, 8 Jun 2006, Neal Norwitz wrote: > If you plan to make a checkin adding a feature (even a simple one), > you oughta let people know by responding to this message. Please get > the bug fixes in ASAP. Remember to add tests! Just to make this appear on this thread: i'm planning to check in t

Re: [Python-Dev] UUID module

On Sat, 10 Jun 2006, Mike Brown wrote: > I have a couple of suggestions for improving that implementation: > > 1. You're currently using os.urandom, which can raise a NotImplementedError. > You should be prepared to fall back on a different PRNG... The latest version (http://zesty.ca/python/uuid.p

Re: [Python-Dev] UUID module

Okay. I have done as Fredrik suggested: > 6. Combine 2 and 3: require the user to pass in a MAC argument > to uuid1, but provide a SlowGetMacAddress helper that wraps > the existing code. I agree with Thomas Wouters: > That sounds like the right thing to do, although I wou

Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses

On Sat, 10 Jun 2006, Greg Ewing wrote: > I'm having trouble seeing a real use for a 0D array as > something distinct from a scalar, as opposed to them > just being an oddity that happens to arise as a side > effect of the way Numeric/Numpy are implemented. I think the whole discussion about the co

[Python-Dev] UUID module

Quite a few people have expressed interest in having UUID functionality in the standard library, and previously on this list some suggested possibly using the uuid.py module i wrote: http://zesty.ca/python/uuid.py This module provides a UUID class, functions for generating version 1, 3, 4, an

[Python-Dev] Missing PyCon 2006

Hi folks. I had been planning to attend PyCon this year and was really looking forward to it, but i need to cancel. I am sorry that i won't be getting to see you all in a couple of weeks. If you know anyone who hasn't yet registered but wants to go, please contact me -- we can transfer my regist

Re: [Python-Dev] Python icon

On Sun, 15 Jan 2006, Georg Brandl wrote: > does Python have an official icon? Not py.ico from PC/, that's a bit > ugly and does not scale. Has no designerhead ever done such a thing? There have been a couple of proposed logos -- i found some images at http://www.pythonology.com/logos -- but i don'

Re: [Python-Dev] Naming conventions in Py3K

On Fri, 30 Dec 2005, Fred L. Drake, Jr. wrote: > On Friday 30 December 2005 06:31, Ka-Ping Yee wrote: > > Is there a really good reason to do that? It's not obvious to me. > > No more than there is to rename None to none or NONE. For that, there is a reason: None is no

Re: [Python-Dev] Naming conventions in Py3K

On Fri, 30 Dec 2005, "Martin v. Löwis" wrote: > Ka-Ping Yee wrote: > > That would be cool. If so, it would make sense for them to be all in > > lowercase. > > And rename None to null in the process :-) Is there a really good reason to do that? It

Re: [Python-Dev] Naming conventions in Py3K

Brett Cannon wrote: > I am fine with changing the built-in types, but changing the built-in > singletons just looks *really* odd to me. So odd that I just don't > want to see them changed. I mean when I think of constants, I think > of a variable that references an object and that reference never

Re: [Python-Dev] Naming conventions in Py3K

On Fri, 30 Dec 2005, Reinhold Birkenfeld wrote: > Ka-Ping Yee wrote: > > Constants in all caps: > > NONE, TRUE, FALSE, ELLIPSIS > > That's ugly. I know it looks ugly to you now. But there's a good reason why we use capitalization for class names -

[Python-Dev] Naming conventions in Py3K

In a fair number of cases, Python doesn't follow its own recommended naming conventions. Changing these things would break backward compatibility, so they are out of the question for Python 2.*, but it would be nice to keep these in mind for Python 3K. Constants in all caps: NONE, TRU

Re: [Python-Dev] a quit that actually quits

On Wed, 28 Dec 2005, Fredrik Lundh wrote: > Ka-Ping Yee wrote > > It sounds to me like what is being proposed amounts to essentially > > "promote sys.exit to a builtin". > no, what's being proposed is what the subject says: a quit/exit command > that actual

Re: [Python-Dev] a quit that actually quits

It sounds to me like what is being proposed amounts to essentially "promote sys.exit to a builtin". So why not do that? I see two options. Either: (a) Simply let __builtins__.exit = sys.exit. Then we get: >>> exit which may be enough of a clue that you type "exit

[Python-Dev] AST manipulation and source code generation

Would there be any interest in extending the compiler package with tools for AST transformations and for emitting Python source code from ASTs? I was experimenting with possible translations for exception chaining and wanted to run some automated tests, so i started playing around with the compile

Re: [Python-Dev] PEP 344: Explicit vs. Implicit Chaining

On Sat, 21 May 2005, James Y Knight wrote: > On May 20, 2005, at 6:37 PM, Phillip J. Eby wrote: > > This only helps if you can get to a debugger. What if you're > > reading your web server's error log? > > Then you're in trouble anyways because you need the contents of some > local to figure out w

Re: [Python-Dev] PEP 344: Implicit Chaining Semantics

On Fri, 20 May 2005, Ka-Ping Yee wrote: > Can be back up and see if we can agree on a specification at a semantic > level first? I've been trying to narrow down exactly what you seem to > intuitively want -- how do you like the following: > >Definition of "context&quo

[Python-Dev] PEP 344: Explicit vs. Implicit Chaining

Guido van Rossum wrote: > Do we really need both __context__ and __cause__? Well, it depends whose needs we're trying to meet. If we want to satisfy those who have been asking for chaining of unexpected secondary exceptions, then we have to provide that on some attribute. If we also want to prov

[Python-Dev] PEP 344: Implicit Chaining Semantics

Guido van Rossum wrote: > try: > BLOCK > except EXCEPTION, VAR: > HANDLER > > I'd like to see this translated into > > try: > BLOCK > except EXCEPTION, VAR: > __context = VAR > try: > HANDLER > except Exception, __error: >

Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks

On Mon, 16 May 2005, Guido van Rossum wrote: > Here's a bunch of commentary: Thanks. Sorry it's taken me a couple of days to get back to this. I think i'm caught up on the mail now. > You're not giving enough credit to Java, which has the "cause" part > nailed IMO. You're right. I missed that.

Re: [Python-Dev] Adding content to exception messages

On Thu, 19 May 2005, Nick Coghlan wrote: > With PEP 344, this could simply be: > >try: >parser.parseFile(file) >exeption Exception, exception: >raise type(exception)("Error at line %s in file %s" % (x,y)) Only if we also made all exceptions new-style classes. That's just a

Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks

On Mon, 16 May 2005, Aahz wrote: > I'll comment here in hopes of staving off responses from multiple > people: I don't think these should be double-underscore attributes. The > currently undocumented ``args`` attribute isn't double-underscore, and I > think that's precedent to be followed. That i

[Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks

This PEP is a concrete proposal for exception chaining, to follow up on its mention here on Python-Dev last week as well as earlier discussions in the past year or two. http://www.python.org/peps/pep-0344.html I've tried to summarize the applications for chaining mentioned in these discussion

Re: [Python-Dev] PEP 343 - Abstract Block Redux

On Sun, 15 May 2005, Guido van Rossum wrote: > In rev 1.10 I moved the __enter__ call out of the > try-block again. Having it inside was insane: when __enter__ fails, it > should do its own cleanup rather than expecting __exit__ to clean up > after a partial __enter__. No, it wasn't insane. You h

Re: [Python-Dev] PEP 343 - Abstract Block Redux

On Sun, 15 May 2005, Shane Hathaway wrote: > You might add to the PEP the following example, which could really > improve the process of building GUIs in Python: > > class MyFrame(Frame): > def __init__(self): > with Panel(): > with VerticalBoxSizer(): >

[Python-Dev] PEP 343: Resource Composition and Idempotent __exit__

Yikes, this turned out to be rather long. Here's a summary: - The expansion suggested by Shane (moving __enter__ outside the try-finally) fits the expectation that __exit__ will always be paired with a successful __enter__. This "paired-exit" expansion is fairly intuitive and makes

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

On Fri, 13 May 2005, Guido van Rossum wrote: > Straight up-or-down votes in the full senate are appreciated at this point. I prefer the "PEP 340 redux" version. Both the flexibility for __enter__ to return a separate object and the ability for __exit__ to react to exceptions are useful. > - Toda

Re: [Python-Dev] Tidier Exceptions

On Thu, 12 May 2005, Guido van Rossum wrote: > How is "except:" less greppable? Duh. I'm slow today. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mail

Re: [Python-Dev] Tidier Exceptions

On Thu, 12 May 2005, Brett C. wrote: > whether bare 'except' statements should go or only catch certain exceptions. Maybe bare 'except' should be spelled 'except *'. I don't think it can be removed altogether because sometimes you just need to be able to do magic, but it can be made a little more

Re: [Python-Dev] Chained Exceptions

On Thu, 12 May 2005, Guido van Rossum wrote: > Define "raise". Does that involve a raise statement? Not necessarily; it could be a raise statement or an inadvertently triggered exception, such as in the example code i posted. > What about 1/0? That counts. > What if you call a method that execu

Re: [Python-Dev] Chained Exceptions

On Thu, 12 May 2005, Brett C. wrote: > Guido van Rossum wrote: > > Try to come up with a precise specification and we'll talk. > > If a new exception is raised (e.g., not a bare 'raise') while a current > exception is active (e.g., sys.exc_info() would return something other > than a tuple of None)

[Python-Dev] Chained Exceptions

Suppose exceptions have an optional "context" attribute, which is set when the exception is raised in the context of handling another exception. Thus: def a(): try: raise AError except: raise BError yields an exception which is an instance of BError.

[Python-Dev] Tidier Exceptions

It occurred to me as i was messing around with handling and re-raising exceptions that tossing around these (type, value, traceback) triples is irritating and error-prone. How about just passing around a single value? All we'd have to do is put the traceback in value.traceback. Implementation:

  1   2   >