Re: [Python-Dev] Terminology for PEP 343
On Monday 04 Jul 2005 03:10, Phillip J. Eby wrote: > At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote: > >[Michael Hudson] > > > This is possible. I just wanted to expand everyone's minds :) > > The mechanism is more general than resourcemanagement. > Expand your mind. :) "Resource" can include whatever objects you want it > to -- or no objects at all. Is printing HTML and guaranteeing ending tags a resource ? I've been reading this thread, and been thinking that Holger Kregel's XPython hack could be implemented using the new with statement. with some_encoding: with html: with body: with h1: print "Some heading" with p: print "This is paragraph 1" with p: print "This is paragraph 2" with h2: print "Another heading" The enter/exit for html would be to print respectively and so on. (Though "p" would be special cased, etc) Personally it seems to me that "with" is more a form of *guarantee* - something that has a guard to enter the block, and something that does something after the block. >From that perspective you could even imagine: with enforce_conditions(pre,post): do some work. ... ... enforce_conditions - enforces the "pre" before entering the block, and may choose to throw an exception if the precondition is false. - checks that "post" holds after the block, and may throw an exception if the postcondition is false. Again, I don't really see that as a resource type scenario. It *may* involve a resource scenario, but it may not. (eg did a condition finish within a certain time?) Perhaps calling it a guarantor? (or similar) * You can guarantee that you have the lock on a resource if you enter the block ? * You can guarantee that you will have properly form (X|HT)ML if using an appropriate approach ? * You can guarantee checking of post conditions in a uniform manner ? (Assumption: That the word guarantee in this case matches that of the intent) If you just call the with statement a "resource manager" I suspect that people will more /naturally/ think just along the idea of resources, rather than also along the lines of things that need guarantees. Is that really a resource type scenario? Best Regards, Michael. -- Michael Sparks, Senior R&D Engineer, Digital Media Group [EMAIL PROTECTED], http://kamaelia.sourceforge.net/ British Broadcasting Corporation, Research and Development Kingswood Warren, Surrey KT20 6NP This e-mail may contain personal views which are not the views of the BBC. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/6/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> Doc strings, first meant for the code reader, need to be where they are.
> They also come before the code itself, so don't interfere.
Doc strings are really not an issue, due to the conventions for
processing whitespace in them (and also the fact that their primary
use is for the reader of the code, even before any automated
processing).
> > -- it's a wart:
>
> That is rather extreme, and is definitely an opinion.
My opinion, certainly. However, I think the fact that workarounds for
the leading whitespace issue are needed (PEP 257, textwrap.dedent("""\
)) points to it being more than that. But of
course that is also my opinion :-)
> And what if I want the leading whitespace left just the way I carefully put
> it?
You can still put leading whitespace as you want it -- there would
just be a slightly different convention to follow -- I'll post what I
wrote up so you can see the whole proposal: better than me repeating
it all in bits.
> And what of existing code dependent on literals being as literal as
> they currently are?
There would be some breakage, certainly -- though I believe it would
be quite little.
> I think the soonest this could be considered is Python
> 3.0.
Quite likely so.
Andrew
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
Here's the draft PEP I wrote up: Abstract Triple-quoted string (TQS henceforth) literals in Python preserve the formatting of the literal string including newlines and whitespace. When a programmer desires no leading whitespace for the lines in a TQS, he must align all lines but the first in the first column, which differs from the syntactic indentation when a TQS occurs within an indented block. This PEP addresses this issue. Motivation TQS's are generally used in two distinct manners: as multiline text used by the program (typically command-line usage information displayed to the user) and as docstrings. Here's a hypothetical but fairly typical example of a TQS as a multiline string: if not interactive_mode: if not parse_command_line(): print """usage: UTIL [OPTION] [FILE]... try `util -h' for more information.""" sys.exit(1) Here the second line of the TQS begins in the first column, which at a glance appears to occur after the close of both "if" blocks. This results in a discrepancy between how the code is parsed and how the user initially sees it, forcing the user to jump the mental hurdle in realising that the call to sys.exit() is actually within the second "if" block. Docstrings on the other hand are usually indented to be more readable, which causes them to have extraneous leading whitespace on most lines. To counteract the problem, PEP 257 [1] specifies a standard algorithm for trimming this whitespace. In the end, the programmer is left with a dilemma: either to align the lines of his TQS to the first column, and sacrifice readability; or to indent it to be readable, but have to deal with unwanted whitespace. This PEP proposes that TQS's should have a certain amount of leading whitespace trimmed by the parser, thus avoiding the drawbacks of the current behaviour. Specification Leading whitespace in TQS's will be dealt with in a similar manner to that proposed in PEP 257: "... strip a uniform amount of indentation from the second and further lines of the [string], equal to the minimum indentation of all non-blank lines after the first line. Any indentation in the first line of the [string] (i.e., up to the first newline) is insignificant and removed. Relative indentation of later lines in the [string] is retained." Note that a line within the TQS that is entirely blank or consists only whitespace will not count toward the minimum indent, and will be retained as a blank line (possibly with some trailing whitespace). There are several significant differences between this proposal and PEP 257's docstring parsing algorithm: * This proposal considers all lines to end at the next newline in the source code (whether escaped or not); PEP 257's algorithm only considers lines to end at the next (necessarily unescaped) newline in the parsed string. * Only literal whitespace is counted; an escape such as \x20 will not be counted as indentation. * Tabs are not converted to spaces. * Blank lines at the beginning and end of the TQS will *not* be stripped. * Leading whitespace on the first line is preserved, as is trailing whitespace on all lines. Rationale I considered several different ways of determining the amount of whitespace to be stripped, including: 1. Determined by the column (after allowing for expanded tabs) of the triple-quote: myverylongvariablename = """\ This line is indented, But this line is not. Note the trailing newline: """ + Easily allows all lines to be indented. - Easily leads to problems due to re-alignment of all but first line when mixed tabs and spaces are used. - Forces programmers to use a particular level of indentation for continuing TQS's. - Unclear whether the lines should align with the triple- quote or immediately after it. - Not backward compatible with most non-docstrings. 2. Determined by the indent level of the second line of the string: myverylongvariablename = """\ This line is not indented (and has no leading newline), But this one is. Note the trailing newline: """ + Allows for flexible alignment of lines. + Mixed tabs and spaces should be fine (as long as they're consisten
Re: [Python-Dev] Terminology for PEP 343
Michael Sparks wrote: > On Monday 04 Jul 2005 03:10, Phillip J. Eby wrote: > >>At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote: >> >>>[Michael Hudson] >>> This is possible. I just wanted to expand everyone's minds :) >>> >>>The mechanism is more general than resourcemanagement. >> >>Expand your mind. :) "Resource" can include whatever objects you want it >>to -- or no objects at all. > > > Is printing HTML and guaranteeing ending tags a resource ? I've been reading > this thread, and been thinking that Holger Kregel's XPython hack could be > implemented using the new with statement. > > with some_encoding: >with html: > with body: > with h1: > print "Some heading" > with p: > print "This is paragraph 1" > with p: > print "This is paragraph 2" > with h2: > print "Another heading" > > The enter/exit for html would be to print respectively and so > on. (Though "p" would be special cased, etc) Phillip's 'context' terminology, on the other hand, applies beautifully: - encoding context - HTML context - HTML body context - HTML heading 1 context - HTML paragraph context I think we have a winner. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Guido van Rossum:
> Ah, sigh. I didn't know that os.listdir() behaves differently when the
> argument is Unicode. Does os.listdir(".") really behave differently
> than os.listdir(u".")?
Yes:
>>> os.listdir(".")
['abc', '']
>>> os.listdir(u".")
[u'abc',
u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435']
> Bah! I don't think that's a very good design
> (although I see where it comes from).
Partly my fault. At the time I was more concerned with making
functionality possible rather than convenient.
> Promoting only those entries
> that need it seems the right solution -- user code that can't deal
> with the Unicode entries shouldn't be used around directories
> containing unicode -- if it needs to work around unicode it should be
> fixed to support that!
OK, I'll work on a patch for that but I'd like to see the opinions
of the usual unicode guys as this will produce more opportunities for
UnicodeDecodeError. The modification will probably work in the
opposite way, asking for all the names in unicode and then attempting
to convert to the default code page with failures retaining the
unicode name.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
OK, here's some draft documentation using Phillip's context terminology. I think it works very well. """ With Statements and Context Management A frequent need in programming is to ensure a particular action is taken after a specific section of code has been executed (such as closing a file or releasing a lock). The tool to achieve this in Python is to use the 'with' statement along with the appropriate context manager. Context managers ensure a particular action is taken to establish the context before the contained suite is entered, and a second action to clean up the context when the suite is exited. The precise behaviour of the 'with' statement is governed by the supplied context manager - an object which supports the context management protocol. This protocol consists of two methods: __enter__(self): Context managers use this method to create the desired context for the execution of the contained suite. This method is called without arguments before the contained suite is entered. If the 'as' clause of the 'with' statement is used, the value returned from this method is assigned to the identified target. Many context managers will return self from this method, but returning a different object may make sense for some managers (e.g. see the 'closing' suite manager example below). __exit__(self, exc_type, exc_value, exc_traceback): Context managers use this method to clean up after execution of the contained suite. This method is called after the contained suite has exited. If the suite was left due to an exception, the details of that exception are passed as arguments. Otherwise, all three arguments are set to None. If exception details are passed in, and this method returns without incident, then the original exception continues to propagate. Otherwise, the exception raised by this method will replace the original exception. Using Contexts to Manage Resources The simplest use of context management is to strictly control the handling of key resources (such as files, generators, database connections, synchronisation locks). These resource managers will generally acquire the resource in their __enter__ method, although some resource managers may accept the resource to be managed as an argument to the constructor or acquire it during construction. Resource managers will then release the resource in their __exit__ method. Some resources (such as threading.Lock) support the context management protocol natively, allowing them to be used directly in 'with' statements. The meaning of the established context will depend on the specific resource. In the case of threading.Lock, the lock is acquired by the __enter__ method, and released by the __exit__ method. More Context Management Examples While resource management may be the most obvious use of the context management protocol, many more uses are possible (otherwise it would have been called the resource management protocol!). For example, when used as a context manager, a decimal.Context object will set itself as the current Decimal arithmetic context in the __enter__ method, and then automatically revert back to the previous Deciaml arithmetic context in the __exit__ method. This allows the code in the contained suite to manipulate the Decimal arithmetic context freely, without needing to worry about manually undoing any changes. Another example is the use of contexts to handle insertion of the appropriate tags when generating HTML: with html: with body: with h1: print "Some heading" with p: print "This is paragraph 1" with p: print "This is paragraph 2" with h2: print "Another heading" Some other possibilities for context management include automatic exception logging and handling of database transactions. Using Generators to Define Context Managers In conjunction with the 'context' decorator, Python's generators provide a convenient way to implement the context management protocol, and share state between the __enter__ and __exit__ methods. The generator must yield exactly once during normal execution. The context manager's __enter__ method executes the generator up to that point, and the value yielded is returned. The remainder of the generator is executed by the context manager's __exit__ method. Any exceptions that occur in the managed context will be injected into the generator at the location of the yield statement. For example, the following context manager allows prompt closure of any resource with a 'close' method (e.g. a generator or file): @context def closing(resource): try: yield resource finally: resource.close() The operation of the context decorator is described by the following Python equivalent (although the exact error messages may differ): class ContextManager(object): def
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/6/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > OK, here's some draft documentation using Phillip's context > terminology. I think it works very well. I agree. +1 on this terminology, and for this explanation to be included in the docs. I also like the fact that it offers a neat 1-word name for the generator decorator, "@context". Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick writes sample documentation: > For example, the following context manager allows prompt closure of > any resource with a 'close' method (e.g. a generator or file): > > @context > def closing(resource): > try: > yield resource > finally: > resource.close() Reading this I get the feeling that perhaps the decorator should be named "context_manager" not "context": @context_manager def closing(resource): try: yield resource finally: resource.close() Does anyone else agree? Paul Moore writes: > I also like the fact that it offers a neat 1-word name for the > generator decorator, "@context". Well, ok... does anyone *else* agree? I too saw this and thought "neat! a simple one-word name!". But then I started worrying that it's not defining the *context*, but rather the *context manager*. While "context manager" is a term I could easily imagine associating only with 'with' statements, "context" is too general a term... even after Python supports 'with' statements I will continue to use "context" to mean lots of different things (eg: decimal.context). By the way, great job Nick... these docs read quite nicely. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
Andrew Durdin wrote: > Here's the draft PEP I wrote up: Well reasoned, and well written up IMO. In particular, being able to preserve all leading whitespace by the simple expedient of putting the closing triple quote in column zero and escaping the final newline is a nice feature. However, while I prefer what you describe to Python's current behaviour, I am not yet convinced the backward compatibility pain is worth it. Adding yet-another-kind-of-string-literal (when we already have bytestrings on the horizon) is also unappealing. Your readability examples are good, but the first two involve strings that should probably be module level constants (as Terry described) and the test case involving expected output is probably better handled using doctest, which has its own mechanism for handling indentation. Raw and unicode string literals need to be mentioned in the PEP. Which literals would the reformatting apply to? All 3? Only standard and unicode, leaving raw strings alone? You should research the reasons why PEP 295 [1] was rejected, and describe in the new PEP how it differs from PEP 295 (unfortunately PEP 295 was not updated with the rationale for rejection, but this post [2] looks like Guido putting the final nail in its coffin). Regards, Nick. [1] http://www.python.org/peps/pep-0295.html [2] http://mail.python.org/pipermail/python-dev/2002-July/026969.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible C API problem?
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Gary Robinson wrote: >> Are the docs wrong or am I misreading them? Or are you wrong? > > It turns out that I am wrong. This is a long standing confusion. At one point, the documentation said what you said, and it was just as wrong. There were even inaccurate PyNoArgsCFunction typedefs in some header! I think Python in a Nutshell is wrong here too. > The NOARGS functions are indeed called with an additional NULL > argument; it's just that many functions with NOARGS in Python itself > are declared without the additional argument. I've been fixing these when I find them, slowly. Fortunately (and obviously, given the lack of bug reports) it won't make any difference with any ABI I know about. Cheers, mwh -- I have gathered a posie of other men's flowers, and nothing but the thread that binds them is my own. -- Montaigne ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Paul Moore wrote: > On 7/6/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > >>OK, here's some draft documentation using Phillip's context >>terminology. I think it works very well. > > > I agree. +1 on this terminology, and for this explanation to be > included in the docs. > > I also like the fact that it offers a neat 1-word name for the > generator decorator, "@context". I liked that too, along with 'ContextManager' as the name for the controlling class that had the highly descriptive name 'Wrapper' in PEP 343. And explaining the operation of specific contexts is generally nice too. Stealing Greg's example: decimal.Context supports the context management protocol, and introduces a new decimal arithmetic context for the duration of the with statement. And the synchronisation example: threading.Lock supports the context management protocol, and acquires the lock for the duration of the with statement. And the generic closing example: closing supports the context management protocol, and closes the supplied resource at the end of the with statement. And the HTML tag examples: The HTML tag objects support the context management protocol, and emit opening and closing tags before and after execution of the body of the with statement. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/6/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > Paul Moore writes: > > I also like the fact that it offers a neat 1-word name for the > > generator decorator, "@context". > > Well, ok... does anyone *else* agree? I too saw this and thought "neat! > a simple one-word name!". But then I started worrying that it's not > defining the *context*, but rather the *context manager*. While > "context manager" is a term I could easily imagine associating only > with 'with' statements, "context" is too general a term... even after > Python supports 'with' statements I will continue to use "context" > to mean lots of different things (eg: decimal.context). Actually, you're starting to persuade me... Although I generally prefer decorator names which are single words. Along with the at-sign, underscores make the whole thing look a little too "punctuation-heavy" for me (and don't suggest camel case, please!). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Paul Moore wrote: > On 7/6/05, Michael Chermside <[EMAIL PROTECTED]> wrote: >> Paul Moore writes: >> > I also like the fact that it offers a neat 1-word name for the >> > generator decorator, "@context". >> >> Well, ok... does anyone *else* agree? I too saw this and thought "neat! >> a simple one-word name!". But then I started worrying that it's not >> defining the *context*, but rather the *context manager*. While >> "context manager" is a term I could easily imagine associating only >> with 'with' statements, "context" is too general a term... even after >> Python supports 'with' statements I will continue to use "context" >> to mean lots of different things (eg: decimal.context). > > Actually, you're starting to persuade me... Although I generally > prefer decorator names which are single words. Along with the at-sign, > underscores make the whole thing look a little too "punctuation-heavy" > for me (and don't suggest camel case, please!). Anything against @contextmanager in analogy to @staticmethod ? Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote: > I have written a patch that changes the way triple-quoted strings are > scanned so that leading whitespace is ignored in much the same way > that pep 257 handles it for docstrings. Largely this was for a > learning experience in hacking the parser, but it would be very nice > IMO if something of this sort could be implemented in a future version > of Python. I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Chaining try statements: eltry?
Hi, this is my first message to this list, so let me say hello first. I want to ask what you think about introducing a keyword 'eltry' which would be the counterpart of 'elif' for try statements. This had been suggested before on python-list a couple of years ago by Jonathan Gardner, but nothing (that I could find) seems to have come of it. Starting from PEP 341, the try statement might be extended to try_stmt: 'try' ':' suite ( (except_clause ':' suite)+ ( 'eltry' ':' suite (except_clause ':' suite)+ )* ['else' ':' suite] ['finally' ':' suite] | 'finally' ':' suite ) where lines 4 through 7 would be an addition to the definition given in the PEP. Admittedly, this looks somewhat complex, but I don't think it actually is. (And while an new keyword always means potentially breaking code, 'eltry' doesn't seem to me a likely identifier chosen by programmers - YMMV.) This extension would be useful whenever a suite of statements is to be terminated as soon as one of them raises an exception, and the programmer is interested in handling those individually. Without 'eltry' the choices are: - Stack conventional try statements, each inside the else clause of the one before. This causes deep nesting, and while typical nesting depths won't be as great as they might become with stacked if statements, it is annoying and ugly IMO. - Run all statements at once and put all exception handlers outside the suite. This yields code that is harder to read than necessary as some handlers will be written far from the statement where the exception they handle is raised. Moreover, if more than one statement may raise a particular exception, some effort is required to find out which one did it if there is only one handler for that exception. - Break up the suite into separate try statements. While this may result in well readable code if each handler breaks out of the block containing the whole run of try statements, it requires some mechanism (such as a wrapper try statement or a separate function that may quit anytime) if exiting the current block is not desired. - Something else, in which case I'm looking forward to learning something new about Python ;o) An example would be a filter chain: def use_eltry(data): # decode as far as possible try: data = foo_decode(data) except ValueError: print "Data seems not to be foo encoded." eltry: data = bar_decode(data) except ValueError: print "Foo decoded data seems not to be bar encoded." eltry: data = baz_decode(data) except ValueError: print "FooBar decoded data seems not to be baz encoded." # whatever data is by now, do something with it do_something(data) def use_stacking(data): # decode as far as possible try: data = foo_decode(data) except ValueError: print "Data seems not to be foo encoded." else: try: data = bar_decode(data) except ValueError: print "Foo decoded data seems not to be bar encoded." else: try: data = baz_decode(data) except ValueError: print "FooBar decoded data seems not to be baz encoded." # whatever data is by now, do something with it do_something(data) def use_single_handler(data): # decode as far as possible try: data = foo_decode(data) data = bar_decode(data) data = baz_decode(data) except ValueError: print "Data could not be decoded, can't tell you why easily." # whatever data is by now, do something with it do_something(data) def use_custom_exception(data): # decode as far as possible try: try: data = foo_decode(data) except ValueError: print "Data seems not to be foo encoded." raise try: data = bar_decode(data) except ValueError: print "Foo decoded data seems not to be bar encoded." raise try: data = baz_decode(data) except ValueError: print "FooBar decoded data seems not to be baz encoded." raise except ValueError: pass # whatever data is by now, do something with it do_something(data) def use_function(data): # decode as far as possible def helper(): try: data = foo_decode(data) except ValueError: print "Data seems not to be foo encoded." return try: data = bar_decode(data) except ValueError: print "Foo decoded data seems not to be bar encoded." return try: data = baz_decode(data) except ValueError: print "FooBar decoded data seems not to be baz encoded." re
Re: [Python-Dev] Triple-quoted strings and indentation
"Andrew Durdin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Here's the draft PEP I wrote up: I believe there were some current alternatives and concerns already expressed that have not been included yet that maybe should be. Some of your examples look worse than needed by putting the first line after the triple quote instead of escaping the first newline like you did elsewhere. Having separate rules for doc strings and other tq strings would be a nuisance. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Chaining try statements: eltry?
On 7/6/05, Thomas Lotze <[EMAIL PROTECTED]> wrote: > I want to ask what you think about introducing a keyword 'eltry' which > would be the counterpart of 'elif' for try statements. This had been > suggested before on python-list a couple of years ago by Jonathan > Gardner, but nothing (that I could find) seems to have come of it. I'm -1 on this. The use case doesn't occur often in my experience and IMO putting each try statement in the else clause of the previous one is a fine solution. I also notice that your only example is very repetitive, and would be better written as a loop, using Python's dynamic nature: for decoder in foo_decode, bar_decode, foobar_decode: try: data = decoder(data) break except ValueError: print "data doesn't seem to be %s-encoded" % decoder.__name__ -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] using pyhon from the MSYS shell
From: "Martin v. Löwis" <[EMAIL PROTECTED]> I'm personally in favour of supporting "MSYS" as a target system. If you want to do it, I'm willing to review patches, but I'm not willing to do them myself, as I don't use MSYS. If you believe that MSYS is a target system in a way similar to mingw32, and to cygwin, actually, MSYS is the package that has the command line tools (i.e. bash, tar, cp, automake, ...) required to be able to compile a native windows binary from a source distribution that is depending on autotools. I believe it should get the same treatment as mingw32 and cygwin. That means all places that currently deal with either of these two systems should also deal with MSYS in a similar way. What this means in actual code, I don't know. OTOH, I already fail to follow you in the very first assumption: why is it that you need to change os.sep on MSYS? "configure" detects what the install-path is (python -c "print os.syspath") which returns C:\Python. MSYS uses a bash shell which does not like "\" but needs "/" as os.sep. Anyways, in the mean time, it's been solved in the m4 files... Maybe it's better to ask the automake guys to support Python with MSYS... Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Expanding max chunk size to 4GB.
The RIFF chunk size (used by the Python wave library) is 2GB, because the length is read as a signed 32-bit integer. The attached patch to chunk.py raises the limit to 4GB by using a signed integer. Is this correct? Is there a more general solution to 32-bit addressing limitation in wave files? Multiple chunks? Set the length field to zero and let software assume we only have one chunk? Regards, Mark Rages [EMAIL PROTECTED] -- You think that it is a secret, but it never has been one. - fortune cookie --- chunk.py2005-07-06 11:39:07.179742573 -0500 +++ chunk.py.orig 2005-07-06 11:36:53.001585367 -0500 @@ -62,7 +62,7 @@ if len(self.chunkname) < 4: raise EOFError try: -self.chunksize = struct.unpack(strflag+'L', file.read(4))[0] +self.chunksize = struct.unpack(strflag+'l', file.read(4))[0] except struct.error: raise EOFError if inclheader: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expanding max chunk size to 4GB.
Looks ok to me, but have you tested this with other software that reads/writes wave files? You seem to be speculating about the format where you should be reading the reference documentation for this file format (alas, I can't help you find it -- you can Google for it as well as I can :). Also, patches, are best submitted to SourceForge. Read python.org/dev/. On 7/6/05, Mark Rages <[EMAIL PROTECTED]> wrote: > The RIFF chunk size (used by the Python wave library) is 2GB, because > the length is read as a signed 32-bit integer. > > The attached patch to chunk.py raises the limit to 4GB by using a > signed integer. > > Is this correct? > > Is there a more general solution to 32-bit addressing limitation in > wave files? Multiple chunks? Set the length field to zero and let > software assume we only have one chunk? > > Regards, > Mark Rages > [EMAIL PROTECTED] > -- > You think that it is a secret, but it never has been one. > - fortune cookie > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Request to add developer
I wish to request that 'gregorykjohnson' be added to the Python SF project. Gregory is the participant I'm mentoring in Google's Summer of Code program. His project is enhancing mailbox.py to give it the ability to modify mailboxes as well as read them; see http://gkj.freeshell.org/summer_of_code/ for his proposal and code sketches. This project seems to belong in nondist/sandbox/ ; I'll impress upon him that he shouldn't commit any changes to mailbox.py in the distribution tree until everything is done. (Trivia: He'll be the fourth 'Greg' or 'Gregory' with Python commit privs, breaking the tie between Gregs and Andrews; currently there are three of each.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request to add developer
> I wish to request that 'gregorykjohnson' be added to the Python SF > project. I'll enable the permissions tonight. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Chaining try statements: eltry?
[Thomas Lotze] > > I want to ask what you think about introducing a keyword 'eltry' > > which would be the counterpart of 'elif' for try statements. This > > had been suggested before on python-list a couple of years ago by > > Jonathan Gardner, but nothing (that I could find) seems to have come > > of it. [Guido] > I'm -1 on this. The use case doesn't occur often in my experience and > IMO putting each try statement in the else clause of the previous one > is a fine solution. > > I also notice that your only example is very repetitive, and would be > better written as a loop, using Python's dynamic nature: > > for decoder in foo_decode, bar_decode, foobar_decode: > try: > data = decoder(data) > break > except ValueError: > print "data doesn't seem to be %s-encoded" % decoder.__name__ FWIW, the looping solution has worked out well in practice. From csv.py: for thisType in [int, long, float, complex]: try: thisType(row[col]) break except (ValueError, OverflowError): pass Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expanding max chunk size to 4GB.
On 7/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Looks ok to me, but have you tested this with other software that > reads/writes wave files? It appears to work, but I haven't done enough testing to be confident. > You seem to be speculating about the format where you should be > reading the reference documentation for this file format (alas, I > can't help you find it -- you can Google for it as well as I can :). This site says it's a "long": http://www.borg.com/~jglatt/tech/wave.htm This site says it's a "ulong": http://www.borg.com/~jglatt/tech/aboutiff.htm Unsigned makes more sense, considering it's a byte count and would never be negative. I've CC'd Erik de Castro Lopo, whose word is more definitive than random websites. > Also, patches, are best submitted to SourceForge. Read python.org/dev/. Oh, sorry, the patch was only to illustrate my idea. I'll submit a proper patch to SF once I hear from Erik. Regards, Mark [EMAIL PROTECTED] -- You think that it is a secret, but it never has been one. - fortune cookie ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expanding max chunk size to 4GB.
Mark Rages wrote: > The RIFF chunk size (used by the Python wave library) is 2GB, because > the length is read as a signed 32-bit integer. > > The attached patch to chunk.py raises the limit to 4GB by using a > signed integer. > > Is this correct? The original Microsoft specification listed the chunk size fields as unsigned 32 bit int, so what you are doing is correct. However, be aware that many programs (particularly on windows) using their own WAV file parsing code do not handle file bigger than 2Gig. > Is there a more general solution to 32-bit addressing limitation in > wave files? No. > Multiple chunks? No. Other file formats allow file sizes larger than 4Gig. I would suggest you have a look at AU and W64. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ Fundamentalist : Someone who is colour blind and yet wants everyone else to see the world with the same lack of colour. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expanding max chunk size to 4GB.
Guido van Rossum wrote: > Looks ok to me, but have you tested this with other software that > reads/writes wave files? Have a look at the sndfile-info program that is distributed as part of libnsdifle. If there is anything wrong with the file you have generated, the output of that program will make it pretty obvious. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Neither noise nor information is predictable." -- Ray Kurzweil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expanding max chunk size to 4GB.
Mark Rages wrote: > This site says it's a "long": http://www.borg.com/~jglatt/tech/wave.htm > This site says it's a "ulong": http://www.borg.com/~jglatt/tech/aboutiff.htm Wonderful isn't it :-). > Unsigned makes more sense, considering it's a byte count and would > never be negative. > > I've CC'd Erik de Castro Lopo, whose word is more definitive than > random websites. libsndfile treats the chunk lengths as unsigned int. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "It's far too easy to make fun of Microsoft products, but it takes a real man to make them work, and a god to make them do anything useful" -- Anonymous ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Well, I'm convinced. My votes go to "context management protocol" and @contextmanager. Simple, descriptive and specific in meaning yet wide enough to cover pretty much all the cases we care about. I think we should state in the docs that the most common usage is to set up a specific context and restore the context to what it was before the with statement at the end of the with statement. Any other use should contain dire warnings ;) This works for the HTML tags - the original context is being outside the tag - and the additional explanation is sufficient warning IMO. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
[Nick Coghlan] > OK, here's some draft documentation using Phillip's context > terminology. I think it works very well. > > """ > With Statements and Context Management > > A frequent need in programming is to ensure a particular action is > taken after a specific section of code has been executed (such as > closing a file or releasing a lock). The tool to achieve this in > Python is to use the 'with' statement along with the appropriate > context manager. "the tool" --> "a tool" The other tool is, of course, try/finally. What is offered by "with" and context manager objects is the encapulsation specific try/finally blocks. This enables repeated, common code to be factored-out. There only new magic here is factoring. Context management has always been possible. > __enter__(self): > __exit__(self, exc_type, exc_value, exc_traceback): These names should be changed to __beginwith__ and __endwith__. The current names are too vague, not obviously paired with each other, not obviously tied to the with-statement, and provide no hint about what calls them. Remember, the methods will appear among a slew of other methods that have nothing to do with with-statements. There will be no surrounding contextual clue as to what these methods are for. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On Wednesday 06 July 2005 19:47, Raymond Hettinger wrote: > These names should be changed to __beginwith__ and __endwith__. The > current names are too vague, not obviously paired with each other, not > obviously tied to the with-statement, and provide no hint about what > calls them. Remember, the methods will appear among a slew of other > methods that have nothing to do with with-statements. There will be no > surrounding contextual clue as to what these methods are for. I don't really like this; what's to say there won't be some other client of the context protocol? Should __iter__ have been __iterfor__? (I don't think so.) If we're worried about name clashes (and in __*__ space, no less!), then perhaps it makes sense to do something like __context__ (similar to __iter__), and use the __enter__ and __exit__ on the result of that method. I'm not convinced there's a need to worry about clashes in the __*__ namespace, but I can see how it might be nice to provide an __context__ method similar to __iter__. But I don't find it compelling, so... let's have __enter__ and __exit__, and be done. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re:Terminology for PEP 343
Raymond Hettinger wrote: > These names should be changed to __beginwith__ and __endwith__. The Alternatively: __begincontext__ / __endcontext__ __enterwith__ / __exitwith__ __entercontext__ / __exitcontext__ __begin_with__ / __end_with__ __begin_context__ / __end_context__ __enter_with__ / __exit_with__ __enter_context__ / __exit_context__ :) Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Fred L. Drake, Jr. wrote: > On Wednesday 06 July 2005 19:47, Raymond Hettinger wrote: > > These names should be changed to __beginwith__ and __endwith__. The > > current names are too vague, not obviously paired with each other, not > > obviously tied to the with-statement, and provide no hint about what > > calls them. Remember, the methods will appear among a slew of other > > methods that have nothing to do with with-statements. There will be no > > surrounding contextual clue as to what these methods are for. > > I don't really like this; what's to say there won't be some other client of > the context protocol? Should __iter__ have been __iterfor__? (I don't think > so.) Then what about __begincontext__ and __endcontext__? Raymond's points about __enter__ and __exit__ are still good. Regards, Nicolas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
+1 on @contextmanager On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote: > > __enter__(self): > > __exit__(self, exc_type, exc_value, exc_traceback): > > These names should be changed to __beginwith__ and __endwith__. -0. My fingers are too hardwired to writing "endswith", as in the string method of similar name. ;) Slightly silly alternative: __within__ and __without__ Otherwise, +0 on __enter__ and __exit__. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GCC version compatibility
Recently people testing Boost.Python with GCC on Linux have reported that the extensions being tested have to be compiled with exactly the same version of GCC as the Python they're being loaded into, or they get mysterious crashes. That doesn't correspond to my past experience; it has always been true that, as long as the compiler used to build Python and the one used to build the extension have compatible 'C' ABIs, we've been okay. Yes, if you were going to pass types like FILE* across the Python/C API, then you additionally need to be sure that the two compilers are using the same 'C' library. That said, none of the Boost.Python tests do that. I'm wondering if there has been a well-known recent change either in Python or GCC that would account for these new reports. Any relevant information would be appreciated. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
