Additional modules to ship with IronPython 2.7.1?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Additional modules to ship with IronPython 2.7.1?

Vernon D. Cole
Dear Group:
  On another thread, Jeff Hardy and "Slide" have commented that they have important standard library modules (unicodedata and csv, respectively) which will not be ready for IronPython 2.7 but should be targeted for 2.7.1.  Jeff also says he may also have sqlite3 ready for prime time by then.   [Well done, guys!]

   I would like to start a discussion about adding modules to the IronPython distribution which are not in the C-Python standard library. The idea would be to include more batteries.  (FePy started out to do that, but has not been seriously updated since IronPython 2.0 came out with a real, genuine Windows installer.)  Good idea, or Bad?

  I see that adodbapi is still getting about 300 downloads a month, and I presume that most of them are for IronPython, since it's already included in pywin32 for CPython users. FePy is getting around 50 downloads a month, which I guess is mostly  to get the dbapi modules. The FePy modules are lighter in weight than adodbapi, and use genuine .NET system calls, but are not completely PEP 249 compliant.  Adodbapi is compliant, but uses COM to read the database, so will not run on linux/mono. Should db api and/or other modules be considered for inclusion?
--
Vernon Cole





_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Additional modules to ship with IronPython 2.7.1?

Jeff Hardy-4
On Wed, Feb 9, 2011 at 12:47 PM, Vernon Cole <[hidden email]> wrote:
> Dear Group:
>    I would like to start a discussion about adding modules to the IronPython
> distribution which are not in the C-Python standard library. The idea would
> be to include more batteries.  (FePy started out to do that, but has not
> been seriously updated since IronPython 2.0 came out with a real, genuine
> Windows installer.)  Good idea, or Bad?

We certainly don't have to restrict ourselves to the same set of
batteries as CPython. However, I'd be cautious about adding in too
much simply because we don't have a huge pool of committers at the
moment.

>
>   I see that adodbapi is still getting about 300 downloads a month, and I
> presume that most of them are for IronPython, since it's already included in
> pywin32 for CPython users. FePy is getting around 50 downloads a month,
> which I guess is mostly  to get the dbapi modules. The FePy modules are
> lighter in weight than adodbapi, and use genuine .NET system calls, but are
> not completely PEP 249 compliant.  Adodbapi is compliant, but uses COM to
> read the database, so will not run on linux/mono. Should db api and/or other
> modules be considered for inclusion?

In the case of adodbapi, the lack of Mono support is slightly
troubling. It's really too bad that dbapi cannot be mapped onto
ADO.NET, but them's the breaks.

Another thing to consider is that a working distutils (and something
like pip) eliminates a lot of the need to have the batteries included.
There's still a bit of work needed to get pip working, but I hope to
have that into 2.7 or 2.7.1.

- Jeff
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Additional modules to ship with IronPython 2.7.1?

briancurtin
On Wed, Feb 16, 2011 at 08:30, Jeff Hardy <[hidden email]> wrote:
On Wed, Feb 9, 2011 at 12:47 PM, Vernon Cole <[hidden email]> wrote:
> Dear Group:
>    I would like to start a discussion about adding modules to the IronPython
> distribution which are not in the C-Python standard library. The idea would
> be to include more batteries.  (FePy started out to do that, but has not
> been seriously updated since IronPython 2.0 came out with a real, genuine
> Windows installer.)  Good idea, or Bad?

We certainly don't have to restrict ourselves to the same set of
batteries as CPython. However, I'd be cautious about adding in too
much simply because we don't have a huge pool of committers at the
moment.

Something to be careful of is inclusion of external code that still evolves outside of the stdlib. When I install 2.7.1 complete with xyz library, a week later when the author comes out with a great new feature, my install is already out of date.

Someone then fixes a bug in the stdlib xyz, which has to propagate to the external version. Along with that, bugs fixed in the external version need to be integrated in the stdlib version, so you'd occasionally have to dump from external, all while being careful of not sneaking in features in bug-fix releases, e.g., for 2.7.2.

Among other things, that's one of the reasons CPython is against further inclusion of externally maintained libraries. The futures package was added for 3.2 and a condition was that it's only home was the stdlib.

- my 0.02c USD

_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Additional modules to ship with IronPython 2.7.1?

Jeff Hardy-4
On Wed, Feb 16, 2011 at 8:18 AM, Brian Curtin <[hidden email]> wrote:

> On Wed, Feb 16, 2011 at 08:30, Jeff Hardy <[hidden email]> wrote:
>>
>> On Wed, Feb 9, 2011 at 12:47 PM, Vernon Cole <[hidden email]>
>> wrote:
>> > Dear Group:
>> >    I would like to start a discussion about adding modules to the
>> > IronPython
>> > distribution which are not in the C-Python standard library. The idea
>> > would
>> > be to include more batteries.  (FePy started out to do that, but has not
>> > been seriously updated since IronPython 2.0 came out with a real,
>> > genuine
>> > Windows installer.)  Good idea, or Bad?
>>
>> We certainly don't have to restrict ourselves to the same set of
>> batteries as CPython. However, I'd be cautious about adding in too
>> much simply because we don't have a huge pool of committers at the
>> moment.
>
> Something to be careful of is inclusion of external code that still evolves
> outside of the stdlib. When I install 2.7.1 complete with xyz library, a
> week later when the author comes out with a great new feature, my install is
> already out of date.

That's my biggest concern. As someone said, the stdlib is where code
goes to die :).

Another consideration is that the Python stdlib may one day become its
own project, and we may not want to diverge from it.

- Jeff
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com