On Tue, Apr 15, 2008 at 7:54 AM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
>
> Just name your patch files .patch or .diff the next time, not .txt, and
> the keyword will get automatically set.
>
fine. I used .txt cause I wanted to view it in my browser (without the
browser asking me for an app
> I think it would be nice if that patch keyword could be set by non-admins.
> This would mean I didn't have to write to the mailing list asking for
> people to look at
> some specific bug. Like "did someone look at
> http://bugs.python.org/issue2122.
Just name your patch files .patch or .diff the
On Wed, Apr 9, 2008 at 7:12 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there another online sprint/bugfix day in the pipeline? If not, can
> there be? ;-)
Trent, I think you just volunteered to lead it. :-)
We should either do it this weekend Apr 19-20 or wait until after the
rel
On Tue, Apr 15, 2008 at 7:21 AM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > I think it would be useful for the tracker to grow a "NeedsReview"
> > keyword. I realize the "patch" keyword does some of this, but it may
> > just represent some initial or trivial work. "NeedsReview" should
> > re
> I think it would be useful for the tracker to grow a "NeedsReview"
> keyword. I realize the "patch" keyword does some of this, but it may
> just represent some initial or trivial work. "NeedsReview" should
> represent a mature patch that some senior dev needs to look hard at
> and make the choice
On Mon, Apr 14, 2008 at 2:56 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> Good idea! A 3to2 project is going to make backporting io.py and other
> new stuff less painful and much faster. For the io.py backport I spent
> most time on removing annotations and replacing "" with u"".
>
> Wha
On Sat, Apr 12, 2008 at 11:02 AM, <[EMAIL PROTECTED]> wrote:
>
> I know this is old stuff, but...
>
> I want to update our Python 2.4 installation at work from 2.4.2 to 2.4.5
> (the latest 2.4 source release). I get a test failure for test_pty, an
> extra ^M at the end of one line. I don't g
I think it would be useful for the tracker to grow a "NeedsReview"
keyword. I realize the "patch" keyword does some of this, but it may
just represent some initial or trivial work. "NeedsReview" should
represent a mature patch that some senior dev needs to look hard at
and make the choice.
--
Che
On Mon, Apr 14, 2008 at 6:59 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I don't think of EOFError as an environmental error... This is quite
>
> > a different level of error than what EnvironmentError typically means
>
> I think it depends. Any "expected" EOFErrors a
Guido van Rossum wrote:
> I don't think of EOFError as an environmental error... This is quite
> a different level of error than what EnvironmentError typically means
I think it depends. Any "expected" EOFErrors are going to be
caught by the surrounding code before propagating very far.
An *uncau
On Mon, Apr 14, 2008 at 4:19 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> But why was imaplib apparently specifying 10MB? Did it know there was
> that much data? Or did it just not want to bother looping over all the
> data in smaller buffer increments (e.g. 64K, which is probably the max
>
On Tue, Apr 15, 2008 at 1:19 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> But why was imaplib apparently specifying 10MB? Did it know there was
> that much data? Or did it just not want to bother looping over all the
> data in smaller buffer increments (e.g. 64K, which is probably the max
>
On Mon, Apr 14, 2008 at 3:57 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
>
>
>
> On Tue, Apr 15, 2008 at 12:19 AM, Curt Hagenlocher <[EMAIL PROTECTED]>
> wrote:
> >
> > On Mon, Apr 14, 2008 at 2:29 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry to reply on the mailing list. But this
On Tue, Apr 15, 2008 at 12:19 AM, Curt Hagenlocher <[EMAIL PROTECTED]>
wrote:
> On Mon, Apr 14, 2008 at 2:29 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> >
> > Sorry to reply on the mailing list. But this change is wrong.
> > e.g. if you're using a buffer size of 16 bytes and try to read 256
> by
On Mon, Apr 14, 2008 at 2:29 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
>
> Sorry to reply on the mailing list. But this change is wrong.
> e.g. if you're using a buffer size of 16 bytes and try to read 256 bytes, it
> should call recv with a value of 256 and not call recv 16 times with a value
>
Collin Winter schrieb:
> It should be pretty easy. I'm working on a 2to3 metaclass fixer, which
> could provide guidance for a 3to2 fixer.
>
> Do we want to take this opportunity to create a real 3to2 project in
> the sandbox? If so, I'd like to refactor lib2to3 into its own project,
> then import
On Mon, Apr 14, 2008 at 11:18 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
>
> On Mon, Apr 14, 2008 at 8:22 PM, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
>
> > Eek! Please use the bug tracker.
> >
>
> I 've made some comments on: http://bugs.python.org/issue1092502 (which is
> the original issu
On Mon, Apr 14, 2008 at 2:26 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Do we want to take this opportunity to create a real 3to2 project in
> > the sandbox? If so, I'd like to refactor lib2to3 into its own project,
> > then import that into 2to3 and 3to2. I can do the work.
>
> In tha
On Mon, Apr 14, 2008 at 8:10 PM, Curt Hagenlocher <[EMAIL PROTECTED]>
wrote:
> On Mon, Apr 14, 2008 at 9:12 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> >
> > I've tracked it down to this change:
> > http://hgpy.de/py/release25-maint/rev/e9446c6ab3cd
> > this is svn revision 61009.
> > [...]
> >
> Do we want to take this opportunity to create a real 3to2 project in
> the sandbox? If so, I'd like to refactor lib2to3 into its own project,
> then import that into 2to3 and 3to2. I can do the work.
In that case, I would propose that the copy in the Python trunk becomes
official, and the other
On Mon, Apr 14, 2008 at 8:22 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Eek! Please use the bug tracker.
>
I 've made some comments on: http://bugs.python.org/issue1092502 (which is
the original issue). However I cannot reopen this issue.
Regards,
- Ralf
__
On Mon, Apr 14, 2008 at 2:05 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> alexandre.vassalotti schrieb:
>
> > Author: alexandre.vassalotti
> > Date: Mon Apr 14 22:51:05 2008
> > New Revision: 62342
> >
> > Log:
> > Improved bytes_extend() to avoid making a full copy of the temporary
> >
alexandre.vassalotti schrieb:
> Author: alexandre.vassalotti
> Date: Mon Apr 14 22:51:05 2008
> New Revision: 62342
>
> Log:
> Improved bytes_extend() to avoid making a full copy of the temporary
> buffer. This also makes the code slightly cleaner.
Changes to Objects/bytesobject.c should be appli
After posting a patch to implement this some good discussion followed
see: http://bugs.python.org/issue2610
It was suggested that a broader discussion might be in order around
the issue of iterators and how they are displayed in the command line
interpreter.
Several new iterators have app
On Mon, Apr 14, 2008 at 12:17 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 14, 2008 at 11:10:12AM -0700, Curt Hagenlocher wrote:
> > while True:
> > left = size - buf_len
> > ! recv_size = max(self._rbufsize, left)
> >
On Mon, Apr 14, 2008 at 11:10:12AM -0700, Curt Hagenlocher wrote:
> while True:
> left = size - buf_len
> ! recv_size = max(self._rbufsize, left)
> data = self._sock.recv(recv_size)
What version is this patch against? (The last 2.5
Offhand, -0. I don't think of EOFError as an environmental error. Its
primary purpose was to have something raised by raw_input() (in 3.0,
input()) when there is no more input. This is quite a different level
of error than what EnvironmentError typically means (a problem in the
filesystem or networ
There's some really convoluted code in socket._fileobject.__init__()
here. When initializing a _fileobject, if the 'bufsize' parameter is
explicitly given as zero, that's turned into an _rbufsize of 1, which,
combined with the 'min' change, will produce the read-one-byte
behavior. The code for se
Eek! Please use the bug tracker.
On Mon, Apr 14, 2008 at 11:10 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 14, 2008 at 9:12 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> >
> > I've tracked it down to this change:
> > http://hgpy.de/py/release25-maint/rev/e9446c6ab3cd
> > this
On Mon, Apr 14, 2008 at 9:12 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
>
> I've tracked it down to this change:
> http://hgpy.de/py/release25-maint/rev/e9446c6ab3cd
> this is svn revision 61009.
> [...]
> self._rbufsize if 1, and so the code reads one byte at a time
The change is correct, but ex
On Mon, Apr 14, 2008 at 6:56 AM, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
> Are pickle files intended to be readable across different machine
> architectures? The documentation states unequivocally that they are
> compatible across Python versions, but compatibility across machine
> architectur
Ralf,
Terry is right. Please file a bug. I do think there may be a problem
with that change but I don't have the time to review it in depth.
Hopefully others will. I do recall that sockets reading one byte at a
time has been a problem before -- I recall a bug about this in the
1.5.2 era for Window
"Ralf Schmitt" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Hi all,
|
| I'm using mercurial with the release25-maint branch. I noticed that
checking
| out a local repository now takes more than
| 5 minutes (it should be around 30s).
|
| I've tracked it down to this change:
| htt
Hi all,
I'm using mercurial with the release25-maint branch. I noticed that checking
out a local repository now takes more than
5 minutes (it should be around 30s).
I've tracked it down to this change:
http://hgpy.de/py/release25-maint/rev/e9446c6ab3cd
this is svn revision 61009. Here is the diff
Are pickle files intended to be readable across different machine
architectures? The documentation states unequivocally that they are
compatible across Python versions, but compatibility across machine
architectures (wrt to differences in size and layout of primitive C
types) is not explicitly add
35 matches
Mail list logo
