Re: [Python-Dev] [Pydotorg] Python 3.0 Porting information

[Martin v. Löwis]

> Do we need to recruit community support
> to get this stuff moving? Experience suggests that "if we build it" they
> will not come unless and until they are led by the nose.

There is

http://pypi.python.org/pypi?:action=browse&c=533
(Programming Language :: Python :: 3)

It currently lists some 20 packages. It might be worthwhile to blog
about that, explaining that if your package isn't listed there even
though it works with Python 3, then you should classify it correctly
right away.

There is also

http://wiki.python.org/moin/Early2to3Migrations

although I'm not sure how useful this is (if the "upstream" package
supports 3.0, and is listed in PyPI, then the PyPI listing is better.
This page might help to collect "forking ports", i.e. where the porter
is not the author).

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] [Pydotorg] Python 3.0 Porting information

[Steve Holden]

Martin v. Löwis wrote:
>> Do we need to recruit community support
>> to get this stuff moving? Experience suggests that "if we build it" they
>> will not come unless and until they are led by the nose.
> 
> There is
> 
> http://pypi.python.org/pypi?:action=browse&c=533
> (Programming Language :: Python :: 3)
> 
> It currently lists some 20 packages. It might be worthwhile to blog
> about that, explaining that if your package isn't listed there even
> though it works with Python 3, then you should classify it correctly
> right away.
> 
> There is also
> 
> http://wiki.python.org/moin/Early2to3Migrations
> 
> although I'm not sure how useful this is (if the "upstream" package
> supports 3.0, and is listed in PyPI, then the PyPI listing is better.
> This page might help to collect "forking ports", i.e. where the porter
> is not the author).
> 
Thanks, Martin.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.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

[Python-Dev] testsuite with tmp/@test

[Kristján Valur Jónsson]

By accident i had a dir called @test in my PCBuild directory when I was running 
the testsuite.
This caused the test_support to define TESTFN as tmp/@test.

This again caused a number of tests to fail.  One issue I have already covered 
in http://bugs.python.org/issue4927
Another issue is test_import which doesn't like importing with filename.
But a lot of tests fail because of incorrect path name delimeters and such.  
Shouldn't we try to make this
work as well as possible even with a temp file that is in a subdirectory?
And, Oh, I'm using windows which aggreviates the issue with the slash/backslash 
confusion.


___
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] Add Py_off_t and related APIs?

[Antoine Pitrou]

Hello,

Python currently has an API to deal with size_t-like numbers (Py_ssize_t,
PyNumber_AsSsize_t), but it doesn't have similar facilities for off_t.

Is it ok to add the following:
 * a Py_off_t type which is typedef'd to either Py_LONG_LONG (Windows) or off_t
(others)
 * three C API functions: PyNumber_AsOff_t, PyLong_AsOff_t, PyLong_FromOff_t
 * an additional type code for PyArg_ParseTuple and friends; I suggest 'N' since
'n' currently means Py_ssize_t, and a Py_off_t should always be at least as wide
as a Py_ssize_t
?

(the motivation is systems where Py_ssize_t is 32-bits wide, but large file
support makes off_t 64 bits wide)

Thanks

Antoine.


___
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] testsuite with tmp/@test

[Brett Cannon]

On Tue, Jan 13, 2009 at 06:09, Kristján Valur Jónsson
 wrote:
> By accident i had a dir called @test in my PCBuild directory when I was
> running the testsuite.
>
> This caused the test_support to define TESTFN as tmp/@test.
>
>
>
> This again caused a number of tests to fail.  One issue I have already
> covered in http://bugs.python.org/issue4927
>
> Another issue is test_import which doesn't like importing with filename.
>
> But a lot of tests fail because of incorrect path name delimeters and such.
> Shouldn't we try to make this
>
> work as well as possible even with a temp file that is in a subdirectory?
>

Yes.Use of TESTFN should assume it is a file but not know exactly
where that file is kept.

-Brett
___
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] Add Py_off_t and related APIs?

[Martin v. Löwis]

> Is it ok to add the following:
>  * a Py_off_t type which is typedef'd to either Py_LONG_LONG (Windows) or 
> off_t
> (others)
>  * three C API functions: PyNumber_AsOff_t, PyLong_AsOff_t, PyLong_FromOff_t
>  * an additional type code for PyArg_ParseTuple and friends; I suggest 'N' 
> since
> 'n' currently means Py_ssize_t, and a Py_off_t should always be at least as 
> wide
> as a Py_ssize_t
> ?

-1. How many functions actually require that type?

> (the motivation is systems where Py_ssize_t is 32-bits wide, but large file
> support makes off_t 64 bits wide)

For argument parsing, you should use "long long" if SIZEOF_OFF_T is 8
and long long is supported, and then assign to off_t as appropriate.

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] Add Py_off_t and related APIs?

[Antoine Pitrou]

Martin v. Löwis  v.loewis.de> writes:
> 
> -1. How many functions actually require that type?

Functions in the IO lib. I can't tell you how many, let's say a dozen.

> > (the motivation is systems where Py_ssize_t is 32-bits wide, but large file
> > support makes off_t 64 bits wide)
> 
> For argument parsing, you should use "long long" if SIZEOF_OFF_T is 8
> and long long is supported, and then assign to off_t as appropriate.

It's wrong, because floats would be accepted as argument to the seek() method.
Hence the need for (at least) PyNumber_AsOff_t.
(of course the IO lib can have its own private implementation of
PyNumber_AsOff_t. But then why not make it benefit everyone?)


___
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] Python History blog started

[Guido van Rossum]

Now that Python has turned 19, I've started blogging about Python's
history. I hope to keep it up at one article per week. So far, I've
written an intro to the series
(http://neopythonic.blogspot.com/2009/01/history-of-python-introduction.html)
and posted two chapters to the history blog itself
(http://python-history.blogspot.com/). Comments are welcome.

While I have a whole series of material ready that started as a draft
HOPL paper that never got published before, eventually I will run out
of material. Therefore I'd like to invite others to write up *their*
recollections. If you were one of the folks who helped create the
newsgroup, or attended an early Python workshop or conference, I would
particularly like to hear from you. (Do you recall "Sproing the
bunny?" Do you own a T-shirt printed by Steve Majewsky? Then by all
means get in touch!)

If you would like to contribute on an ongoing basis, I'd be happy to
add you to the blog as an author, so you can post your own articles. I
also would like to hear from people who contributed more recently --
it is no longer the case that I know all that's going on in the
community. Let's make this a group project!

-- 
--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] Add Py_off_t and related APIs?

[Nick Coghlan]

Antoine Pitrou wrote:
> Martin v. Löwis  v.loewis.de> writes:
>> -1. How many functions actually require that type?
> 
> Functions in the IO lib. I can't tell you how many, let's say a dozen.
> 
>>> (the motivation is systems where Py_ssize_t is 32-bits wide, but large file
>>> support makes off_t 64 bits wide)
>> For argument parsing, you should use "long long" if SIZEOF_OFF_T is 8
>> and long long is supported, and then assign to off_t as appropriate.
> 
> It's wrong, because floats would be accepted as argument to the seek() method.
> Hence the need for (at least) PyNumber_AsOff_t.
> (of course the IO lib can have its own private implementation of
> PyNumber_AsOff_t. But then why not make it benefit everyone?)

If the IO lib file support is solid, file access code will generally be
using that API and not need to worry about the vagaries of off_t
themselves*.

I'd say start with the private version in IO lib, and then if there is
demand consider moving it to abstract.h (but, like Martin, I don't
expect such demand to ever develop).

Cheers,
Nick.

* As another step is made on the road to version independent C extensions...

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Add Py_off_t and related APIs?

[Martin v. Löwis]

>> For argument parsing, you should use "long long" if SIZEOF_OFF_T is 8
>> and long long is supported, and then assign to off_t as appropriate.
> 
> It's wrong, because floats would be accepted as argument to the seek() method.

I see.

> Hence the need for (at least) PyNumber_AsOff_t.
> (of course the IO lib can have its own private implementation of
> PyNumber_AsOff_t. But then why not make it benefit everyone?)

I would do this through a converter function (O&), but yes,
making it private to the io library sounds about right. Who
else would benefit from it?

If we start with that, we end up with ParseTuple formats for
uid_t, gid_t, pid_t, and the other dozen integral types that
POSIX has invented.

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] Add Py_off_t and related APIs?

[Antoine Pitrou]

Nick Coghlan  gmail.com> writes:
> 
> I'd say start with the private version in IO lib, and then if there is
> demand consider moving it to abstract.h (but, like Martin, I don't
> expect such demand to ever develop).

Ok, I'm gonna do this.

Thanks

Antoine.


___
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] Add Py_off_t and related APIs?

[Victor Stinner]

Le Tuesday 13 January 2009 21:33:28 Martin v. Löwis, vous avez écrit :
> I would do this through a converter function (O&), but yes,
> making it private to the io library sounds about right. Who
> else would benefit from it?

On Linux, mmap() prototype is:

   void *mmap(void *start, size_t length, int prot, int flags,
int fd, off_t offset);

mmapmodule.c uses "Py_ssize_t" type and _GetMapSize() private function to 
convert the long integer to the Py_ssize_t type.

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] Add Py_off_t and related APIs?

[Victor Stinner]

Le Tuesday 13 January 2009 22:47:52 Victor Stinner, vous avez écrit :
> Le Tuesday 13 January 2009 21:33:28 Martin v. Löwis, vous avez écrit :
> > I would do this through a converter function (O&), but yes,
> > making it private to the io library sounds about right. Who
> > else would benefit from it?
>
> On Linux, mmap() prototype is (...)

A more complete answer... Current usage of off_t types in Python:

(1) mmap.mmap(): [use Py_ssize_t]

Use "Py_ssize_t i = PyNumber_AsSsize_t(o, PyExc_OverflowError)".

(2) posix.lseek(), posix.ftruncate(), fcnt.lockf(): [off_t, 
struct flock for fcntl.lockf()]

Use PyInt_AsLong(posobj),
or "PyLong_Check(posobj)? PyLong_AsLongLong(posobj) : PyInt_AsLong(posobj)"
if HAVE_LARGEFILE_SUPPORT.

(3) posix.stat(): [struct win32_stat/struct stat]

use PyInt_FromLong(st->st_size),
or PyLong_FromLongLong((PY_LONG_LONG)st->st_size) if HAVE_LARGEFILE_SUPPORT

---

Using >>find /usr/include -name "*.h"|xargs grep -H off_t<< I found:
 - file operations:
   * lseek(), truncate(), fseeko(), ftello()
   * file size in the *stat() structure
   * (fcntl) lockf(), fadvice(), fallocate()
   * pread(), pwrite()
   * async I/O like aio_read()
 - dirent structure used by readir()
 - sendfile()
 - mmap()

Some libraries define their own offset type:
 - [gzip] z_off_t used by gzseek(), gztell() defined as a long
 - [mysql] my_off_t is unsigned long, or ulonglong size if sizeof(off_t) > 4,
   os_off_t is off_t
 - etc.

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] Add Py_off_t and related APIs?

[Daniel Stutzbach]

On Tue, Jan 13, 2009 at 2:33 PM, "Martin v. Löwis" wrote:

> If we start with that, we end up with ParseTuple formats for
> uid_t, gid_t, pid_t, and the other dozen integral types that
> POSIX has invented.
>

Perhaps it would be useful to provide generic support for integer types that
might have different widths on different platforms?  e.g.:

uid_t uid = PyNumber_AS_INT_BY_SIZE(number_ob, uid_t);

That way, the core does not need to know about every blah_t type used by
POSIX and extension modules, while offering convenient conversion functions
nonetheless.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Add Py_off_t and related APIs?

[Martin v. Löwis]

> Perhaps it would be useful to provide generic support for integer types
> that might have different widths on different platforms?  e.g.:
> 
> uid_t uid = PyNumber_AS_INT_BY_SIZE(number_ob, uid_t);
> 
> That way, the core does not need to know about every blah_t type used by
> POSIX and extension modules, while offering convenient conversion
> functions nonetheless.

I don't think that this would be that useful. What might help is support
for parsing arbitrary-sized integers in PyArg_ParseTuple, as this should
typically be the path through which you get the valud into the (say) uid
variable.

However, it's still then fairly tricky: is uid_t a signed type or an
unsigned type; if unsigned, can I still have negative values (which, for
uid_t, I often can), does the platform have uid_t in the first place,
and, if not, what other type should I use? and so on.

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

[Python-Dev] should list's call to __len__ swallow SystemExit?

[Dino Viehland]

We had a bug reported that effectively boils down to we’re not swallowing 
exceptions when list calls __len__ 
(http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=20598).

We can obviously make the change to catch exceptions here in IronPython even if 
it seems like a bad idea to me ☺  But CPython seems to catch not only normal 
exceptions, but also SystemExit.  It seems like there’s been a move away from 
this so I thought I’d mention it here.  I tested it on 2.6.1 and 3.0.

import sys
class A(object):
def __iter__(self): return iter(range(10))
def __len__(self):
try:
print('exiting')
sys.exit(1)
except Exception as e:
print('can I catch it?', e)

list(A())

which prints:

exiting
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]


___
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] should list's call to __len__ swallow SystemExit?

[Guido van Rossum]

There seems to be an unconditional PyErr_Clear() in
_PyObject_LengthHint(). I think that could and should be much more
careful; it probably should only ignore AttributeErrors (though there
may be unittests to the contrary).

On Tue, Jan 13, 2009 at 8:24 PM, Dino Viehland  wrote:
> We had a bug reported that effectively boils down to we're not swallowing 
> exceptions when list calls __len__ 
> (http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=20598).
>
> We can obviously make the change to catch exceptions here in IronPython even 
> if it seems like a bad idea to me ☺  But CPython seems to catch not only 
> normal exceptions, but also SystemExit.  It seems like there's been a move 
> away from this so I thought I'd mention it here.  I tested it on 2.6.1 and 
> 3.0.
>
> import sys
> class A(object):
>def __iter__(self): return iter(range(10))
>def __len__(self):
>try:
>print('exiting')
>sys.exit(1)
>except Exception as e:
>print('can I catch it?', e)
>
> list(A())
>
> which prints:
>
> exiting
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
>
> ___
> 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