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
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
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
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
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
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 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
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.
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
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
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
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_
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
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
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
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 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
> 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 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
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;
-
-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
[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
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
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 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
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
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
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
It's important to realize that most operating systems (Windows, OS X)
don't really support the use
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
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
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
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
33 matches
Mail list logo
