On 8/19/06, Samuele Pedroni <[EMAIL PROTECTED]> wrote:> Given that the meaning of annotations is meant not be predefined,Not sure what that has to do with it.
> given that people are comining with arbitrarely verbose examples> thereof,Which I believe are worst-case scenarios and not what we'll see
Hi,
as
raise ValueError, "something went wrong"
is going to go away, how will one raise with a custom traceback?
The obvious
raise ValueError("something went wrong"), traceback
or something more esoteric like
raise ValueError("something went wrong") with traceback
?
Georg
The 'with' syntax is attractive because it will flag all unconverted
code as a syntax error.
I wonder if "raise ValueError" should still be allowed (as equivalent
to "raise ValueError()") or that it should be disallowed.
--Guido
On 8/20/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> as
>
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I wonder if "raise ValueError" should still be allowed (as equivalent
> to "raise ValueError()") or that it should be disallowed.
+1 for disallow.
raise is a simple rule to remember.
Having VE == VE() in certain
I've created a wiki page with some ideas for Python 3000 things we
could do at the Google sprint (starting Monday). See:
http://wiki.python.org/moin/GoogleSprintPy3k
For general info about this sprint -- it's not too late to come! -- see:
http://wiki.python.org/moin/GoogleSprint
--
--Guido
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 20, 2006, at 11:53 AM, Guido van Rossum wrote:
> The 'with' syntax is attractive because it will flag all unconverted
> code as a syntax error.
>
> I wonder if "raise ValueError" should still be allowed (as equivalent
> to "raise ValueError()")
Terry Reedy wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> I wonder if "raise ValueError" should still be allowed (as equivalent
>> to "raise ValueError()") or that it should be disallowed.
>
> +1 for disallow.
>
> raise is a simple rule to remember.
Guido van Rossum schrieb:
> Are you interested in doing this at the Google sprint next week?
Sure; I hadn't any special plans so far.
> What do you think?
Sounds good. There are two problems I see:
- how to benchmark?
- there are subtle details in the API that require changes
to extension co
On 8/20/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Are you interested in doing this at the Google sprint next week?
>
> Sure; I hadn't any special plans so far.
>
> > What do you think?
>
> Sounds good. There are two problems I see:
>
> - how to benchmark?
We
On 8/19/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 8/19/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> ... don't understand the virtue of bringing
> decorators into the picture. Yes, they are
> one consumer of metadata.
They aren't being brought in as sample *consumers*; they are being
suggested
Hi Guido,
On 8/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I've created a wiki page with some ideas for Python 3000 things we
> could do at the Google sprint (starting Monday). See:
>
> http://wiki.python.org/moin/GoogleSprintPy3k
I'm interested in contribute with the task "Rewrite imp
Excellent! I'm adding Brett to the CC's. Can you update the wiki page
adding your name to that task? Are you coming to the sprint in person
or are you just going to be sprinting at your own place?
--Guido
On 8/20/06, Osvaldo Santana <[EMAIL PROTECTED]> wrote:
> Hi Guido,
>
> On 8/20/06, Guido van
On 8/20/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
We're discussing the alternative of>>> def f(a:int, b):which is better for some things -- but much worse for others; if themetadata is any longer than int, it is almost certainly worse. So (I
believe) he is suggesting that we just reuse decorator s
On 8/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Excellent! I'm adding Brett to the CC's.
Cool. Has Brett planned something to this rewrite?
> Can you update the wiki page adding your name to that task?
Done.
> Are you coming to the sprint in person
> or are you just going to be sprint
On 8/20/06, Osvaldo Santana <[EMAIL PROTECTED]> wrote:
> On 8/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Excellent! I'm adding Brett to the CC's.
>
> Cool. Has Brett planned something to this rewrite?
I'm not sure exactly what you are asking. It's mostly planned to be a
re-implementat
On 8/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I've created a wiki page with some ideas for Python 3000 things we
> could do at the Google sprint (starting Monday). See:
>
> http://wiki.python.org/moin/GoogleSprintPy3k
I notice that one of the items on there is "Work on the new I/O
li
Paul Prescod wrote:
> I guess I still don't really understand what he's getting at or what the
> value of @callmeta is in that example. It just seems like extra noise
> with no value to me...
>
> Ron: what *precisely* does the @callmeta decorator do? If you can
> express it in code, so much th
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> The fatal error strikes me as unpleasant. Perhaps PyInt_Check[Exact]
> should return false if the value won't fit in a C long?
Maybe.
> Or perhaps we could just return -sys.maxint-1?
This would be a bad idea: some errors in use programs would yie
Paul Prescod schrieb:
> Thanks for everyone who contributed. It seems that the emerging
> consensus (bar a security question from Guido) is that ctypes it the way
> forward for calling C code in Python 3000.
I don't think that can ever work (so I don't participate in that
consensus). There are to
For the implementation of Implement PEP [PEP]3102 - Keyword Only
Argument, it would be nice to have a (abstract) data structure
representing the signature of a function. Currently, the code object
only has # of arguments, # of default values, so if we want to allow
something like,
def foo(a,b=10,
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > given the precedent of type inferenced languages
> > that use a separate line for optional type information
>
> Can you show us an example or two?
C/C++ probably doesn't count, being that type information is required,
but one can relocate type in
On 20/08/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/19/06, Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> > given the precedent of type inferenced languages
> > that use a separate line for optional type information
>
> Can you show us an example or two?
Haskell:
map :: (a -> b) -> [a]
On 8/20/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 8/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I've created a wiki page with some ideas for Python 3000 things we
> > could do at the Google sprint (starting Monday). See:
> >
> > http://wiki.python.org/moin/GoogleSprintPy3k
>
> I n
Guido van Rossum wrote:
> On 8/20/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> Without endorsing every detail of his design, tomer filiba has written
> several blog (?) entries about this, the latest being
> http://sebulba.wikispaces.com/project+iostack+v2 . You can also look
> at sandbox/sio/sio.p
On 8/20/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/20/06, Paul Moore <[EMAIL PROTECTED]> wrote:
>
> > Without endorsing every detail of his design, tomer filiba has written
> > several blog (?) entries about this, the latest being
> > http://sebulba.wikispaces.com/proje
Terry Reedy wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>I wonder if "raise ValueError" should still be allowed (as equivalent
>>to "raise ValueError()") or that it should be disallowed.
>
> +1 for disallow.
Seems like that would break a lot of c
Guido van Rossum wrote:
> On 8/20/06, Talin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > On 8/20/06, Paul Moore <[EMAIL PROTECTED]> wrote:
>>
>> > Without endorsing every detail of his design, tomer filiba has written
>> > several blog (?) entries about this, the latest being
>> > htt
Guido van Rossum python.org> writes:
[snip]
>>> Without endorsing every detail of his design, tomer filiba has written
>>> several blog (?) entries about this, the latest being
>>> http://sebulba.wikispaces.com/project+iostack+v2 . You can also look
>>> at sandbox/sio/sio.py in svn.
[snip]
>
> T
Alexander Belopolsky schrieb:
> For Py3k, I would like to suggest a buffer protocol modelled
> after iovec structure that is used by the readv system call.
> On many systems readv is more efficient than repeated calls
> to read and I think Py3k will benefit from a direct access to
> that feature.
On 8/20/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/20/06, Talin <[EMAIL PROTECTED]> wrote:
> >> Guido van Rossum wrote:
> >> > On 8/20/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> >>
> >> > Without endorsing every detail of his design, tomer filiba has written
> >> > sev
On Aug 21, 2006, at 12:01 AM, Martin v. Löwis wrote:
> Alexander Belopolsky schrieb:
>> For Py3k, I would like to suggest a buffer protocol modelled
>> after iovec structure that is used by the readv system call.
>> On many systems readv is more efficient than repeated calls
>> to read and I thin
Guido van Rossum wrote:
> On 8/20/06, Talin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
> How sure are you of all that? I always thought that these have about
> the same age, and that the main distinction is byte vs. char
> orientation. Also, the InputStreamReader class clearly sits on to
32 matches
Mail list logo
