On 3/1/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
What we have now:
def f(a, b, *args, **dict(c=1)): # Yuck!
What we really need:
def f(a, b, *args, **, c=1): # Two stars spell dictionary.
What I heard was planned instead:
def f(a, b, *args, *, c=1):
What we have now:
def f(a, b, *args, **dict(c=1)): # Yuck!
What we really need:
def f(a, b, *args, **, c=1): # Two stars spell dictionary.
What I heard was planned instead:
def f(a, b, *args, *, c=1): # One star spells iterable.
Two stars make a nice visual
Greg Ewing wrote:
> Talin wrote:
>
>> A typical example of what I am talking about here is something like a
>> web application server, where you have a "development" mode and a
>> "production" mode. In the development mode, you want to find errors as
>> quickly as possible, so you enable strict
On 2/28/07, Talin <[EMAIL PROTECTED]> wrote:
[SNIP]
> >
> > 5. The "strict mode" activation through a global state on the string object
> > is a bad idea. I would prefer some sort of "flags" argument passed to each
> > function. I would prefer the "strict" mode where exceptions are raised by
> > de
Talin wrote:
> A typical example of what I am talking about here is something like a
> web application server, where you have a "development" mode and a
> "production" mode. In the development mode, you want to find errors as
> quickly as possible, so you enable strict formatting. In production
> Travis E. Oliphant wrote:
>
>
>>Yes, this was the reason for my dtype object. But, I think that folks
>>felt it was too much, especially since the struct-style syntax is
>>already there in Python.
>
>
> Making it a full-blown Python object would be too much
> for this application. But it c
Daniel Stutzbach wrote:
> On 2/27/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>>But I've heard that the reference counts on
>>Python objects can be larger than 1 in some cases (even though there
>>isn't really anything "viewing" the memory).
>
> Is that true?
The interpreter machinery some
Travis E. Oliphant wrote:
> Yes, this was the reason for my dtype object. But, I think that folks
> felt it was too much, especially since the struct-style syntax is
> already there in Python.
Making it a full-blown Python object would be too much
for this application. But it could be somethin
I just uploaded Patch 1671314 to SourceForge with a C implementation
of a Raw File I/O type, along with unit tests. It still needs work
(especially for supporting very large files and non-unixy systems),
but should serve as a very good starting point.
On 2/26/07, Mike Verdone <[EMAIL PROTECTED]>
Hi Talin,
Some more thoughts...
> Here's my primary issue with this: I wanted a way to enable strictness
> on an application-wide level, without having to go and individually
> revise the many (typically hundreds) of individual calls to the string
> formatting function.
>
> A typical example of w
Pete Shinners wrote:
> I've gone over PEP3101 to create an initial unittest for the advanced
> formatting. Based on this intro to the formatting syntax, I thought I'd
> also
> share my thoughts. I've also experimented with this against the python
> prototype of the formatting.
>
> I have commente
On 2/28/07, Jack Diederich <[EMAIL PROTECTED]> wrote:
[snip]
> History and Implementation
> ==
>
> Class decorators were originally proposed in PEP318 [1]_ and were rejected
> by Guido [2]_ for lack of use cases. Two years later he saw a use case
> he liked and gave the go-
Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> >Travis Oliphant <[EMAIL PROTECTED]> wrote:
> >>I think you are right. In the discussions for unifying string/unicode I
> >>really like the proposals that are leaning toward having a unicode
> >>object be an immutable string o
Josiah Carlson wrote:
>Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
>>I think you are right. In the discussions for unifying string/unicode I
>>really like the proposals that are leaning toward having a unicode
>>object be an immutable string of either ucs-1, ucs-2, or ucs-4 depending
>>on
Greetings from PyCon!
I read hundreds of emails in the dozens of threads about class decorators and
there was surprisingly little content (most of the arguments were about syntax
which is no longer up for debate). As a result this PEP is quite plain.
If any IronPython or Jython folks could throw
Travis Oliphant <[EMAIL PROTECTED]> wrote:
> I think you are right. In the discussions for unifying string/unicode I
> really like the proposals that are leaning toward having a unicode
> object be an immutable string of either ucs-1, ucs-2, or ucs-4 depending
> on what is in the string.
Exce
Thomas Heller wrote:
>
>>Additions to the struct string-syntax
>>
>> The struct string-syntax is missing some characters to fully
>> implement data-format descriptions already available elsewhere (in
>> ctypes and NumPy for example). Here are the proposed additions:
>>
>> Character
Should FileIO objects define the following methods and properties that
the Python 2 file object defines?
mode
name
closed
isatty
Secondly, should any of these be bumped up to the Raw I/O ABC?
--
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC
___
Hi Pete,
These look very good. My comments to your comments below,
> 1. The early python implementation does not allow "reusing" an argument
> either by index or by keyword name. The PEP has not defined this behavior. I
> think it is important to be allowed to reuse any of the argument objects
>
On 2/28/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >On EOF, they return a length-0 object or 0 instead. If the user tries
> >to read again *after* hitting EOF, then an EOFError is raised.
>
> What is the motivation for having two different ways to signal EOF? How
> is this case handled?
I've gone over PEP3101 to create an initial unittest for the advanced
formatting. Based on this intro to the formatting syntax, I thought I'd also
share my thoughts. I've also experimented with this against the python
prototype of the formatting.
I have commented out the tests where that implemen
On 2/27/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Maybe I'm not understanding you correctly. Perhaps what you are saying
> is that we should have all memory allocation go through a light-weight
> memory-object. Then, you would get this object + an offset when you
> wanted a pointer into
On Wed, 28 Feb 2007 07:39:33 -0600, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
>> - Should read()/readinto() raise EOFError?
>
>On EOF, they return a length-0 object or 0 instead. If the user tries
>to read again *after* hitting EOF, then an EOFError is raised.
>
What is the motivat
Note: to make my answers true, I had to change the Non-blocking I/O
part of the PEP so that .read(), .write(), and .readinto() all return
None if no data is available from a non-blocking object. Previously
it had specified that .readinto() would return 0, but I realized this
would be ambiguous wi
Travis E. Oliphant schrieb:
> Attached is my current draft of the enhanced buffer protocol for Python
> 3000. It is basically what has been discussed except for some issues
> with non single-segment memory areas (such as a sub-array).
>
> Comments are welcome.
>
> -Travis Oliphant
> Addition
[reposting since the first time it didn't get through...]
On 26/02/2007 22.35, Mike Verdone wrote:
> Daniel Stutzbach and I have prepared a draft PEP for the new IO system
> for Python 3000. This document is, hopefully, true to the info that
> Guido wrote on the whiteboards here at PyCon. Thi
26 matches
Mail list logo
