On Sat, Aug 25, 2007, Guido van Rossum wrote:
>
> I believe the only reasonable solution is to promote the use of
> package managers, and to let go of the "batteries included" philosophy
> where it comes to major external functionality. When it links to
> something that requires me to do install a
On Sun, Aug 26, 2007, Neil Schemenauer wrote:
> Brett Cannon <[EMAIL PROTECTED]> wrote:
>>
>> I don't like the former, but the latter is intriguing. If we could
>> host large packages (e.g., email, sqlite, ctypes, etc.) on python.org
>> by providing tracker, svn, and web space they could be develo
Brett Cannon <[EMAIL PROTECTED]> wrote:
> I don't like the former, but the latter is intriguing. If we could
> host large packages (e.g., email, sqlite, ctypes, etc.) on python.org
> by providing tracker, svn, and web space they could be developed and
> released on their own schedule. Then the Py
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Now, there's plenty of pure Python (or Python-specific) functionality
> for which "batteries included" makes total sense, including the email
> package, wsgiref, XML processing, and more; it's often a judgement
> call. But I want to warn against the des
> On 8/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I believe the only reasonable solution is to promote the use of
> package managers, and to let go of the "batteries included" philosophy
It's important to realize that most operating systems (Windows, OS X)
don't really support the use
On 8/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I ran 2to3 over the Doc/tools directory. This left a number of problems
> which I initially began replacing manually. I then realized that it would
> be better to tweak 2to3. A couple things I wondered about:
>
> 1. How are we suppos
On 8/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I believe the only reasonable solution is to promote the use of
> package managers, and to let go of the "batteries included" philosophy
> where it comes to major external functionality. When it links to
> something that requires me to do i
heh good point. ignore that thought. python is a signed language. :)
On 8/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I look at it from another POV -- does anyone care about not being able
> to represent dimensionalities over 2 billion? I don't see the
> advantage of saying unsigned in
I ran 2to3 over the Doc/tools directory. This left a number of problems
which I initially began replacing manually. I then realized that it would
be better to tweak 2to3. A couple things I wondered about:
1. How are we supposed to maintain changes to Doc/tools? Running svn
status do
Um, that patch contains only the C code for overloading isinstance()
and issubclass().
Did you do anything about abc.py and _abcoll.py/collections.py and
their respective unit tests? Or what about the unit tests for
isinstance()/issubclass()?
On 8/25/07, Benjamin Aranguren <[EMAIL PROTECTED]> wro
I look at it from another POV -- does anyone care about not being able
to represent dimensionalities over 2 billion? I don't see the
advantage of saying unsigned int here; it just means that we'll get
more compiler warnings in code that is otherwise fine. After all, the
previous line says 'int read
[Subject was: Removing email package until it's fixed]
I find there are pluses and minuses to the "batteries included"
philosophy. Not so much in the case of the email package (which I'm
sure will be back before 3.0 final is released), but in general, in
order for a package to be suitable for incl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 25, 2007, at 7:00 PM, Bill Janssen wrote:
>> FWIW, I'm very much against moving email out of the core. This has
>> been discussed a number of times before, and as far as I am aware, no
>> conclusion reached. However, the "batteries included" ap
Anyone mind if I do this?
--- Include/object.h(revision 57412)
+++ Include/object.h(working copy)
@@ -148,7 +148,7 @@
Py_ssize_t itemsize; /* This is Py_ssize_t so it can be
pointed to by strides in simple case.*/
int readonly;
-
On 8/25/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > FWIW, I'm very much against moving email out of the core. This has
> > been discussed a number of times before, and as far as I am aware, no
> > conclusion reached. However, the "batteries included" approach of
> > Python is a huge benefit for
> FWIW, I'm very much against moving email out of the core. This has
> been discussed a number of times before, and as far as I am aware, no
> conclusion reached. However, the "batteries included" approach of
> Python is a huge benefit for me.
I agree. But if the current code doesn't work with 3K
On 25/08/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 8/25/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> > On Aug 25, 2007, at 9:36 AM, Guido van Rossum wrote:
> > > FYI, I'm removing the email package from the py3k branch for now.
> > > If/when Barry has a working version we'll add it back. Give
On Sat, Aug 25, 2007 at 03:00:15PM -0700, Brett Cannon wrote:
> On 8/25/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> > Alternately, we could move toward separate libraries for such
> > components; this allows separate packages to have separate
> > maintenance cycles, and makes it easier for applicat
On 8/25/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Aug 25, 2007, at 9:36 AM, Guido van Rossum wrote:
> > FYI, I'm removing the email package from the py3k branch for now.
> > If/when Barry has a working version we'll add it back. Given that it's
> > so close to the release I'd rather release wi
Worked with Alex Martelli at the Goolge Python Sprint.
Index: Objects/abstract.c
===
--- Objects/abstract.c (revision 57470)
+++ Objects/abstract.c (working copy)
@@ -2275,6 +2275,27 @@
int
PyObject_IsInstance(PyObject *inst, PyObjec
Works for me. Barry?
On 8/25/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Aug 25, 2007, at 9:36 AM, Guido van Rossum wrote:
> > FYI, I'm removing the email package from the py3k branch for now.
> > If/when Barry has a working version we'll add it back. Given that it's
> > so close to the release
On Fri, Aug 24, 2007 at 08:30:48PM -0700, Neal Norwitz wrote:
> On 8/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > Guido> Are there any existing uses (in the core) that are hard to
> > > Guido> replace with PyArg_
On Aug 25, 2007, at 9:36 AM, Guido van Rossum wrote:
> FYI, I'm removing the email package from the py3k branch for now.
> If/when Barry has a working version we'll add it back. Given that it's
> so close to the release I'd rather release without the email package
> than with a broken one. If Barry
Guido van Rossum wrote:
> Would you mind uploading this to the new tracker at bugs.python.org?
> And you can close the predecessor of the patch there (unless you want
> to reuse that one).
>
> (If you're having trouble using the tracker, you may need to reset
> your password -- it'll send an email
Would you mind uploading this to the new tracker at bugs.python.org?
And you can close the predecessor of the patch there (unless you want
to reuse that one).
(If you're having trouble using the tracker, you may need to reset
your password -- it'll send an email with a new password to your SF
acco
On 8/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Can we put this decision off till after the a1 release?
Yes.
> At this point
> I don't expect PyString to be removed in time for the release, which I
> want to be done by August 31.
Agreed. I plan to make a patch for this and upload it.
The patch improves io.py and socket.py's SocketIO:
* I've removed all asserts and replaces them by explict raises
* I've added four convenient methods _check_readable, _check_writable,
_check_seekable and _check_closed. The methods take an optional msg
argument for future usage.
* unit tests for t
Thanks, applied.
There's a lot more to bing able to run "make html PYTHON=python3.0"
successfully, isn't there?
On 8/25/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> The patch fixes roman.py for Py3k (<> and raise fixes).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
The patch fixes roman.py for Py3k (<> and raise fixes).
Christian
Index: Doc/tools/roman.py
===
--- Doc/tools/roman.py (revision 57462)
+++ Doc/tools/roman.py (working copy)
@@ -40,9 +40,9 @@
def toRoman(n):
"""convert integer t
Neal> with Python/mactoolboxglue.c looking like it's low hanging fruit,
I already took care of the easy cases there, though I haven't checked it in
yet.
Neal> The remaining 65 uses are in Mac modules. I'm not sure if all of
Neal> them are sticking around. (That's a separate discuss
FYI, I'm removing the email package from the py3k branch for now.
If/when Barry has a working version we'll add it back. Given that it's
so close to the release I'd rather release without the email package
than with a broken one. If Barry finishes it after the a1 release,
people who need it can alw
Can we put this decision off till after the a1 release? At this point
I don't expect PyString to be removed in time for the release, which I
want to be done by August 31.
On 8/24/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 8/24/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > I see in PEP 358
Martin> As for the case of timemodule: the surprising feature is that
Martin> "(ii)" uses PySequence_Getitem to access the fields, whereas
Martin> PyArg_ParseTuple uses PyTuple_GET_ITEM, so it won't work for
Martin> StructSequences.
I believe I've already fixed this (r57416) by in
33 matches
Mail list logo
