Re: [Python-Dev] Python VM

2008-07-22 Thread Jakob Sievers
I added a page to wiki.python.org:
  http://wiki.python.org/moin/CPythonVmInternals
This incorporates most of  Martin v. Löwis's additions (except for a
few bits which
I need to look into more).

In any case, thanks for the feedback!
Cheers,
-jakob
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] fileobj.read(float): warning or error?

2008-07-22 Thread John J Lee

On Tue, 22 Jul 2008, Cameron Simpson wrote:
[...]

Leaving aside the 0.2 => 0 converstion, shouldn't read() raise an
exception if asked for < 1 bytes? Or is there a legitimate use for read(0)
with which I was not previously aware?


http://docs.python.org/lib/bltin-file-objects.html

read([size])

... If the size argument is negative or omitted, read all data until EOF 
is reached. ...



John

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] fileobj.read(float): warning or error?

2008-07-22 Thread Cameron Simpson
On 22Jul2008 20:56, John J Lee <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Jul 2008, Cameron Simpson wrote:
> [...]
>> Leaving aside the 0.2 => 0 converstion, shouldn't read() raise an
>> exception if asked for < 1 bytes? Or is there a legitimate use for read(0)
>> with which I was not previously aware?
>
> http://docs.python.org/lib/bltin-file-objects.html
>
> read([size])
>
> ... If the size argument is negative or omitted, read all data until EOF  
> is reached. ...

Hmm, yeah, but 0 is not negative and not omitted so this does not apply.

Personally I'm not very fond of that spec; I'm good with the omitted size
provoking a "read everything" mode but I'd rather a non-numeric value like
None rather than a negative one (eg the conventional "def read(size=None)")
if an explicit size should do so. That way bad arithmetic in the caller
could have a chance of triggering an exception from read instead of a
silent (and to my taste, nasty) "slurp the file" mode.
-- 
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] fileobj.read(float): warning or error?

2008-07-22 Thread John J Lee

On Wed, 23 Jul 2008, Cameron Simpson wrote:

On 22Jul2008 20:56, John J Lee <[EMAIL PROTECTED]> wrote:

On Tue, 22 Jul 2008, Cameron Simpson wrote:
[...]

Leaving aside the 0.2 => 0 converstion, shouldn't read() raise an
exception if asked for < 1 bytes? Or is there a legitimate use for read(0)
with which I was not previously aware?


http://docs.python.org/lib/bltin-file-objects.html

read([size])

... If the size argument is negative or omitted, read all data until EOF
is reached. ...


Hmm, yeah, but 0 is not negative and not omitted so this does not apply.


Well, -1 *is* < 1 (and is in the domain of the function), but yes -- 
sorry, read too quickly, took your "< 1" too literally.



John

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] fileobj.read(float): warning or error?

2008-07-22 Thread Cameron Simpson
On 21Jul2008 23:35, Leif Walsh <[EMAIL PROTECTED]> wrote:
| On Tue, 22 Jul 2008, Cameron Simpson wrote:
| > Leaving aside the 0.2 => 0 converstion, shouldn't read() raise an
| > exception if asked for < 1 bytes? Or is there a legitimate use for
| > read(0) with which I was not previously aware?
| 
| I think read(0) should be a no-op, just like it is in libc.  This lets
| you write 'read(bytes)' without worrying about checking bytes, and
| also lets you silently stop reading when you have no more space, like
| in the following:
| 
| buf = f.read(max(bytes_left, page_size))
| while buf:
|   process(buf)  # updates bytes_left
|   buf = f.read(max(bytes_left, page_size))

[ Don't you mean "min()"? Unimportant. ]

I see the convenience here, but doubt I'd ever do that myself.
I'd write the above like this:

  while bytes_left > 0:
buf = f.read(max(bytes_left, page_size))
if buf == 0:
  break
process(buf)  # updates bytes_left

I'm kind of picky about doing things exactly as often as required and no
more. Especially things that call another facility.

read(0) itself must internally have a check for size == 0 anyway, so
it's not like the overall system is less complex. If we're unlucky it
could trickle all the way down to an OS system call to read(2) (UNIX,
substitute as suitable elsewhere) and for a no-op that would be overkill
by far. The only way the read() implementation would avoid that is by
doing the test on size anyway. But since read() is opaque IMO it is
better to avoid it at the upper level if we know it will produce
nothing.

Which leaves me unconvinced of the utility of this mode.

Cheers,
-- 
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] fileobj.read(float): warning or error?

2008-07-22 Thread Victor Stinner
Le Monday 21 July 2008 21:23:21, vous avez écrit :
> > It should raises an error instead of a warning, it has no sense to read a
> > partial byte :-) But that should breaks some applications?
>
> This doesn't come into effect until 3.0.

Would it possible to create an option "strict mode" which disallow dangerous 
cast? Especially in PyArg_Parse*() functions.

--

I hate "transparent" cast, like C and PHP do everywhere. The 
worst "transparent" cast in Python (2.x) is between str (bytes) and unicode 
(characters) types.

Victor Stinner aka haypo
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] fileobj.read(float): warning or error?

2008-07-22 Thread Benjamin Peterson
On Tue, Jul 22, 2008 at 6:43 PM, Victor Stinner <
[EMAIL PROTECTED]> wrote:

> Le Monday 21 July 2008 21:23:21, vous avez écrit :
> > > It should raises an error instead of a warning, it has no sense to read
> a
> > > partial byte :-) But that should breaks some applications?
> >
> > This doesn't come into effect until 3.0.
>
> Would it possible to create an option "strict mode" which disallow
> dangerous
> cast? Especially in PyArg_Parse*() functions.


You could use -Wall to make the warning an error.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] fileobj.read(float): warning or error?

2008-07-22 Thread Benjamin Peterson
On Tue, Jul 22, 2008 at 6:47 PM, Benjamin Peterson <
[EMAIL PROTECTED]> wrote:

>
>
> On Tue, Jul 22, 2008 at 6:43 PM, Victor Stinner <
> [EMAIL PROTECTED]> wrote:
>
>> Le Monday 21 July 2008 21:23:21, vous avez écrit :
>> > > It should raises an error instead of a warning, it has no sense to
>> read a
>> > > partial byte :-) But that should breaks some applications?
>> >
>> > This doesn't come into effect until 3.0.
>>
>> Would it possible to create an option "strict mode" which disallow
>> dangerous
>> cast? Especially in PyArg_Parse*() functions.
>
>
> You could use -Wall to make the warning an error.
>

I meant -Werr.

>
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] fileobj.read(float): warning or error?

2008-07-22 Thread Leif Walsh
On Tue, Jul 22, 2008 at 3:46 PM, Cameron Simpson <[EMAIL PROTECTED]> wrote:
> [ Don't you mean "min()"? Unimportant. ]

Haha, that's what I get for not actually _running_ the code example.

> I see the convenience here, but doubt I'd ever do that myself.
> I'd write the above like this:
>
>  while bytes_left > 0:
>buf = f.read(max(bytes_left, page_size))
>if buf == 0:
>  break
>process(buf)  # updates bytes_left
>
> I'm kind of picky about doing things exactly as often as required and no
> more. Especially things that call another facility.

I do the same, but I know lots of people that prefer the example I
sent earlier.  Also, if we ever adopt the "while ... as ..." syntax
(here's not hoping) currently being discussed in another thread,
having read(0) return None or an empty buffer will cause that idiom to
short circuit as well.

> read(0) itself must internally have a check for size == 0 anyway, so
> it's not like the overall system is less complex. If we're unlucky it
> could trickle all the way down to an OS system call to read(2) (UNIX,
> substitute as suitable elsewhere) and for a no-op that would be overkill
> by far. The only way the read() implementation would avoid that is by
> doing the test on size anyway. But since read() is opaque IMO it is
> better to avoid it at the upper level if we know it will produce
> nothing.

If we are going to make read(0) a no-op, we should definitely do it
before it hits the underlying implementation, for portability's sake.

On Tue, Jul 22, 2008 at 4:43 PM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Would it possible to create an option "strict mode" which disallow dangerous
> cast? Especially in PyArg_Parse*() functions.

Ack!  We're not writing Perl here, guys.  Can we please not start
having multiple subsets of the language that are separately valid?

-- 
Cheers,
Leif
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com