Re: [Python-Dev] Triple-quoted strings and indentation
Andrew Durdin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In general, I find triple-quoted strings to be very handy, particularly for standalone scripts. However, the fact that they have to be written in the left-hand column to avoid leading whitespace really grates, particularly when they're nested within a block or two At present I think I would do usage_text = '''\ text how I want it ''' perhaps in global context or at top of function and then try: options, args = getopt.getopt(sys.argv[1:], cf:s) except getopt.GetoptError: print usage_text I long ago found it advantageous to pull message texts from scattered locations into a central place where easier to find and edit. I also make program logic easier to read without a long block in the way. YMMV 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. -- it's a wart: That is rather extreme, and is definitely an opinion. I have written a patch that changes the way triple-quoted strings are scanned so that leading whitespace is ignored. And what if I want the leading whitespace left just the way I carefully put it? And what of existing code dependent on literals being as literal as they currently are? I think the soonest this could be considered is Python 3.0. 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] 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(\ text begins on next line)) 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 consistent). -
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 html /html 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] 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
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
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] '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 html 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
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
