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] 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 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, 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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

[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] 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

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] 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] 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] 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] 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] 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

[Python-Dev] Shorthand for lambda

Hey folks, I'm sitting over here in the AppleScript talk and Jacob is explaining a module called 'appscript' that interfaces to the Apple Events system. What caught my eye was this example: from appscript import * ab = app('Address Book') people = ab.people.filter(its.emails != [])

Re: [Python-Dev] Shorthand for lambda

On Wed, 23 Mar 2005, Josiah Carlson wrote: > Paul Moore <[EMAIL PROTECTED]> wrote: > > I thought about it, but couldn't convince myself that it would work > > properly in all cases. I was thinking in terms of operator overloading > > of everything possible - how did you do it? > > PyTables allows s

Re: [Python-Dev] Re: Shorthand for lambda

On Wed, 23 Mar 2005, Reinhold Birkenfeld wrote: > What does you implementation do for this: > > >>> somevar = False > >>> filter(_ and False, numbers) It fails. (For the same reason that __len__ doesn't work -- Python insists that __nonzero__ must return an int.) Though i must say i have no idea

Re: [Python-Dev] Security capabilities in Python

On Fri, 8 Apr 2005, Eyal Lotem wrote: > I would like to experiment with security based on Python references as > security capabilities. This is an interesting and worthwhile thought. Several people (including myself) have talked about the possibility of doing this in the past. I believe the two

Re: [Python-Dev] Re: Security capabilities in Python

On Sat, 9 Apr 2005, Fredrik Lundh wrote: > Ka-Ping wrote: > > counter = Counter() > > readonly_facet = facet(counter, ['value']) > > > > If i've done this correctly, it should be impossible to alter the > > contents of the list or the counter, given only the immutable_facet > > or the reado

Re: [Python-Dev] Security capabilities in Python

On Sat, 9 Apr 2005, Jp Calderone wrote: > Does using the gc module to bypass this security count? If so: > > [EMAIL PROTECTED]:~$ python -i facet.py > >>> import gc > >>> c = readonly_facet.__getattr__.func_closure[1] > >>> r = gc.get_referents(c)[0] > >>> r.n = 'hax0r3d' >

Re: [Python-Dev] Security capabilities in Python

On Sat, 9 Apr 2005, Michael Hudson wrote: > The funniest I know is part of PyPy: > > def extract_cell_content(c): > """Get the value contained in a CPython 'cell', as read through > the func_closure of a function object.""" > # yuk! this is all I could come up with that works in Python

Re: [Python-Dev] Security capabilities in Python

On Sat, 9 Apr 2005, James Y Knight wrote: > You can protect against this, too, but it does show that it's *really* > hard to get restricting code right... Good point. If you can't trust ==, then you're hosed. > I'm of the opinion that it's not > really worth it -- you should just use OS protecti

Re: [Python-Dev] Security capabilities in Python

On Sun, 10 Apr 2005, Eyal Lotem wrote: > It may be really hard to get it right, unless we are overlooking some simple > solution. To "get it right", you at least need to know exactly what your operators mean. I messed up because i failed to realize that '==' can be redefined, and 'in' depends on

[Python-Dev] Check out a new way to read threaded conversations.

I hope you will not mind too much if I ask a small favor. Sorry for this off-topic post. I am working on a new design for displaying online conversations. (Some of you saw this at PyCon.) I'm conducting a short survey to gather some opinions on the current design. If you have just a few minutes

Re: [Python-Dev] anonymous blocks

On Thu, 21 Apr 2005, Guido van Rossum wrote: > Perhaps it could be even simpler: > > [assignment_target '=']* expr ':' suite > > This would just be an extension of the regular assignment statement. It sounds like you are very close to simply translating expression... function_call(args):

Re: [Python-Dev] anonymous blocks

On Thu, 21 Apr 2005, Guido van Rossum wrote: > The use cases where the block actually returns a value are probably > callbacks for things like sort() or map(); I have to admit that I'd > rather keep lambda for these (and use named functions for longer > blocks) than introduce an anonymous block syn

Re: [Python-Dev] Re: anonymous blocks

On Mon, 25 Apr 2005, Brett C. wrote: > It executes the body, calling next() on the argument name on each > time through until the iteration stops. There's a little more to it than that. But on the whole I do support the goal of finding a simple, short description of what this construct is intende

Re: [Python-Dev] Re: anonymous blocks

On Thu, 28 Apr 2005, Greg Ewing wrote: > If such an explanation can't be found, I strongly suspect > that this doesn't correspond to a cohesive enough concept > to be made into a built-in language feature. If you can't > give a short, understandable explanation of it, then it's > probably a bad ide

Re: [Python-Dev] PEP 340: syntax suggestion - try opening(filename) as f:

On Fri, 29 Apr 2005, Guido van Rossum wrote: > The more I think about it the more I like having no keyword at all > (see other messages). I hope you'll reconsider this. I really think introducing a new statement requires a keyword, for pedagogical reasons as well as readability and consistency.

[Python-Dev] Keyword for block statements

On Fri, 29 Apr 2005, Phillip J. Eby wrote: > At 08:21 PM 4/29/05 -0500, Ka-Ping Yee wrote: > >All the statements in Python are associated with keywords, except > >for assignment, which is simple and extremely common. I don't > >think the block statement is simple e

Re: [Python-Dev] PEP 340: Breaking out.

On Wed, 4 May 2005, Shane Hathaway wrote: > I'd like to suggest a small language enhancement that would fix this > example. Allow the break and continue statements to use a keyword, > either "for" or "while", to state that the code should break out of both > the block statement and the innermost "

Re: [Python-Dev] PEP 340 -- loose ends

Reinhold Birkenfeld wrote: > There is one problem with using no keyword: You cannot use arbitrary > expressions in the new statement. [...] > resource = opening("file.txt") > resource: > (...) > > The latter would have to be forbidden. Noam Raphael wrote: > Can you explain why it would have to

Re: [Python-Dev] PEP 340: Breaking out.

On Thu, 5 May 2005, Delaney, Timothy C (Timothy) wrote: > Aahz wrote: > > My standard workaround is using exceptions, but I'm not sure how that > > interacts with a block: > > > > try: > > for name in filenames: > > with opened(name) as f: > > if f.read(2) ==

Re: [Python-Dev] PEP 340: Breaking out.

On Fri, 6 May 2005, Nick Coghlan wrote: > Either way, my latest and greatest version of the non-looping block statement > semantics can be found here: > http://mail.python.org/pipermail/python-dev/2005-May/053400.html My mind is not made up, but i did find this proposal pretty appealing. I'd love

Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340

On Fri, 6 May 2005, Guido van Rossum wrote: > There's one alternative possible (still orthogonal to PEP 340): > instead of __next__(), we could add an optional argument to the next() > method, and forget about the next() built-in. I prefer your original proposal. I think this is a good time to sw

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

On Wed, 11 May 2005, Guido van Rossum wrote: > [Steven Bethard] > > exc = () > > try: > > try: > > BLOCK1 > > except: > > exc = sys.exc_info() > > finally: > > stmt_exit(*exc) > > > > would this make any of the examples impossible to write

[Python-Dev] "with" use case: exception chaining

> - Ka-ping Yee thinks we need separate entry points for the exceptional > and the normal termination case. I disagree; this would end up in > unnecessary duplication of code (or boilerplate to equate the two > methods) in most cases. The whole *point* is that finally gets t

[Python-Dev] "with" use case: replacing a file

Here's another use case to think about. Example 2: Replacing a File. Suppose we want to reliably replace a file. We require that either: (a) The file is completely replaced with the new contents; or (b) the filesystem is unchanged and a meaningful exception is thrown. We'd like to be able

Re: [Python-Dev] "with" use case: exception chaining

On Thu, 12 May 2005, Guido van Rossum wrote: > [Ka-Ping Yee] > > Example 1: Exception Chaining. > > > > As has been previously discussed, the information from an exception can > > be lost when the handling of the exception runs into a problem. It is > > often

[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:

[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.

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)

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] 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] 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] 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

[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] 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(): >

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

[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 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

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, 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.

[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: >

[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

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

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

[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

[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

[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

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

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] 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] 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

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] 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] 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: > [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] 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

[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

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

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 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 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] 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 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] 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] 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] 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 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, 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 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] 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] 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 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 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 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] 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] 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: > 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

[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

  1   2   >