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
+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
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
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__ / __ex
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. Remembe
[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 execute
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 re
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 C
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 ma
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
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
[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
> 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://mai
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
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, p
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?
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, a
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
"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 put
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
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 pars
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-
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 st
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 fac
"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 eve
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, whi
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:
> r
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
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
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\
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.
>>
>>Exp
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 bu
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 f
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 incl
34 matches
Mail list logo
