Py3k is progressing nicely. We are planning the first alpha sometime
this week. The tests are mostly passing. With all the churn over the
last week, I'm sure it's about to change. :-) AFAIK, nearly all the
tests pass on Linux and Mac OS X. There was a report that Windows/VC8
was able to build
Hello,
Neal Norwitz wrote:
> There was a report that Windows/VC8
> was able to build python but it crashed in test_builtin. Can anyone
> confirm this?
After some more digging:
- Only the debug build is concerned. No crash with a release build.
- The crash is a stack overflow.
- the failing funct
On Fri, Aug 24, 2007 at 09:58:24AM -0700, Gregory P. Smith wrote:
> On Thu, Aug 23, 2007 at 09:17:04PM -0700, Guido van Rossum wrote:
> > On 8/23/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > Gregory P. Smith wrote:
> > > > Wasn't a past mailing list thread claiming the bytes type was supposed
>
Neal> The string/unicode merge is making good progress. There are less
Neal> than 400 references to PyString. Most of the references are in
Neal> about 5-10 modules. Less than 50 modules in the core have any
Neal> references to PyString. We still need help converting over to us
Neal Norwitz schrieb:
> Py3k is progressing nicely. We are planning the first alpha sometime
> this week. The tests are mostly passing. With all the churn over the
> last week, I'm sure it's about to change. :-) AFAIK, nearly all the
> tests pass on Linux and Mac OS X. There was a report that
Thomas Heller schrieb:
> Neal Norwitz schrieb:
>> Py3k is progressing nicely. We are planning the first alpha sometime
>> this week. The tests are mostly passing. With all the churn over the
>> last week, I'm sure it's about to change. :-) AFAIK, nearly all the
>> tests pass on Linux and Mac O
On 8/27/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> So I converted _bsddb.c to use the buffer API everywhere only to find
> that bytes objects don't support the PyBUF_LOCKDATA option of the
> buffer API... I should've seen that coming. :) Anyways I opened a
> bug to track that. Its needed
On 8/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> As someone who hasn't participated in the string->unicode conversion up to
> this point (not even looking at any of the hundreds of related checkins)
> it's not at all obvious how to correctly replace PyString_* with PyUnicode_*
> in any gi
>> Also, given that we are close, shouldn't a few buildbots be set up?
Guido> Agreed. Neal tried to set up a buildbot on the only machine he
Guido> can easily use for this, but that's the "old gentoo box" where he
Guido> keeps getting signal 32. (I suspect this may be a kernel bug
On Sun, Aug 26, 2007, Neil Schemenauer wrote:
> Aahz <[EMAIL PROTECTED]> wrote:
>>
>> -0 on the idea of making "batteries included" include PyPI packages.
>> Anything part of "batteries included" IMO should just be part of the
>> standard install.
>
> I think you misunderstand the proposal. The "
On 8/26/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Aahz <[EMAIL PROTECTED]> wrote:
> > -0 on the idea of making "batteries included" include PyPI packages.
> > Anything part of "batteries included" IMO should just be part of the
> > standard install.
>
> I think you misunderstand the proposa
On 8/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But I'm wondering if passing a Unicode string to the various hash
> digest functions should work at all! Hashes are defined on sequences
> of bytes, and IMO we should insist on the user to pass us bytes, and
> not second-guess what to do wit
On 8/27/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 8/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > But I'm wondering if passing a Unicode string to the various hash
> > digest functions should work at all! Hashes are defined on sequences
> > of bytes, and IMO we should insist on the us
Hi,
sorry if this has been answered before, I search the mailing list and
didn't find anything.
I'd like to ask if the modules in the standard library will comply
with PEP 8. I've always found it weird that - in the logging module,
for example - I have to get the logger via getLogger instead of
g
On 8/27/07, Dennis Brakhane <[EMAIL PROTECTED]> wrote:
> Hi,
>
> sorry if this has been answered before, I search the mailing list and
> didn't find anything.
>
> I'd like to ask if the modules in the standard library will comply
> with PEP 8. I've always found it weird that - in the logging module
Guido van Rossum schrieb:
> Thanks, applied.
>
> There's a lot more to bing able to run "make html PYTHON=python3.0"
> successfully, isn't there?
Yes, there is; IMO it won't have to work for alpha1, but I'll work on this
during the next few weeks.
Georg
--
Thus spake the Lord: Thou shalt inden
On 8/27/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Thanks, applied.
> >
> > There's a lot more to bing able to run "make html PYTHON=python3.0"
> > successfully, isn't there?
>
> Yes, there is; IMO it won't have to work for alpha1, but I'll work on this
> during the
[EMAIL PROTECTED] schrieb:
> 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
Dennis Brakhane wrote:
> I'd like to ask if the modules in the standard library will comply
> with PEP 8. I've always found it weird that - in the logging module,
> for example - I have to get the logger via getLogger instead of
> get_logger. I understand that the logging module is older than PEP 8
On Mon, Aug 27, 2007 at 11:21:21AM -0600, Adam Olsen wrote:
> This would complicate the work of various packaging systems.
You're not getting it. The tarball that we distribute as a Python
release would look basically like it does now (i.e. it would include
things like the "email" package). I ca
On 8/27/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Dennis Brakhane wrote:
> > I'd like to ask if the modules in the standard library will comply
> > with PEP 8. I've always found it weird that - in the logging module,
> > for example - I have to get the logger via getLogger instead of
> > ge
Guido van Rossum wrote:
> Let's not start another bikeshed color debate. The PEP has been
> discussed, discussed again, and accepted.
*g* :]
I was on the verge of writing that I don't want to start another bike
shed [1] discussion ...
Christian
[1]
http://www.freebsd.org/cgi/getmsg.cgi?fetch=50
I'm still working on stricter enforcement of the "don't mix str and
bytes" rule. I'm finding a lot of trivial problems, which are
relatively easy to fix but time-consuming.
While doing this, I realize there are two idioms for converting a str
to bytes: s.encode(e) or bytes(s, e). These have identi
> Message: 10
> Date: Mon, 27 Aug 2007 13:05:13 -0700
> From: "Guido van Rossum" <[EMAIL PROTECTED]>
> Subject: Re: [Python-3000] Will standard library modules comply with
> PEP 8?
> To: "Christian Heimes" <[EMAIL PROTECTED]>
> Cc: python-3000@python.org
> Message-ID:
> <[EMAIL PROTECTE
+1 from me, i don't see a reason for bytes(s, e) to exist when
s.encode(e) does the same job and is more symmetric.
On 8/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm still working on stricter enforcement of the "don't mix str and
> bytes" rule. I'm finding a lot of trivial problems, wh
As anyone following the py3k checkins should have figured out by now,
I'm on a mission to require all code to be consistent about bytes vs.
str. For example binary files will soon refuse str arguments to
write(), and vice versa.
I have a patch that turns on this enforcement, but I have anout 14
fa
On 8/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Hm, why not just create the temporary file in binary mode and wrap an
> io.TextIOWrapper instance around it?
That works, but leaves TemporaryFile with a text mode that is somewhat
crippled. TemporaryFile unconditionally uses the default
Gregory P. Smith writes:
> heh good point. ignore that thought. python is a signed language. :)
For what little it's worth, I object strongly. The problem isn't
Python, it's C. Because the rules give unsigned precedence over
signed in implicit conversions, mixed signed/unsigned arithmetic i
OK, I think you've convinced me.
Now, how about also making the default mode be text instead of binary?
I've got a hunch that text files are used more than binary files, even
where temporary files are concerned.
--Guido
On 8/27/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
> On 8/26/07, Guido van Ros
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 27, 2007, at 4:38 PM, Guido van Rossum wrote:
> I'm still working on stricter enforcement of the "don't mix str and
> bytes" rule. I'm finding a lot of trivial problems, which are
> relatively easy to fix but time-consuming.
>
> While doing thi
This patch (already in the tracker) fixes test_csv:
http://bugs.python.org/issue1033
On 8/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> As anyone following the py3k checkins should have figured out by now,
> I'm on a mission to require all code to be consistent about bytes vs.
> str. For e
On 8/27/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Aug 27, 2007, at 4:38 PM, Guido van Rossum wrote:
>
> > I'm still working on stricter enforcement of the "don't mix str and
> > bytes" rule. I'm finding a lot of trivial problems, which are
> > relatively easy to fix but time-consuming.
> >
>
On 8/27/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> On Aug 27, 2007, at 6:16 PM, [EMAIL PROTECTED] wrote:
>
> > I would like to see PEP 8 remove the "as necessary to improve
> > readability" in the function and method naming conventions. That
> > way methods like StringIO.getvalue() can be ren
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 27, 2007, at 6:16 PM, [EMAIL PROTECTED] wrote:
> I would like to see PEP 8 remove the "as necessary to improve
> readability" in the function and method naming conventions. That
> way methods like StringIO.getvalue() can be renamed to
>
[EMAIL PROTECTED] writes:
> Python can't include all the major packages but it is necessary for any
> language to support a good GUI package in order to be widely adopted
> by the masses. [...] My vote would
> be for wxPython but I'm not someone who truly cares much about GUIs
> as I mu
So it does! Thanks! (Did you perchance borrow my time machine? :-)
--Guido
On 8/27/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
> This patch (already in the tracker) fixes test_csv:
>
> http://bugs.python.org/issue1033
>
> On 8/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > As anyone followin
Barry Warsaw writes:
> Stephen, sorry to hear about your daughter and I hope she's going to
> be okay of course!
Oh, she's *fine*. There's just a conflict between the Japanese
practice of vaccinating all school children against TB, and the
U.S. practice of testing for TB antibodies. About 1
Stephen J. Turnbull wrote:
> [EMAIL PROTECTED] writes:
>
> > Python can't include all the major packages but it is necessary for any
> > language to support a good GUI package in order to be widely adopted
> > by the masses. [...] My vote would
> > be for wxPython but I'm not someone who
Guido van Rossum wrote:
> someone evil could still produce a phase error by
> changing the contents while you're looking at it (basically sabotaging
> their own application) but I don't see how they could cause a segfault
> that way.
Maybe not in the same program, but if the data is
output from th
Gregory P. Smith wrote:
> A thought that just occurred to me... Would a PyBUF_CANONICAL flag be
> useful instead of CHARACTERS?
I don't think the buffer API should be allowing for
anything that requires, or could require, the provider
to convert the data into a different form. It should
stick to
Guido van Rossum wrote:
> I think we can't really drop s.encode(), for symmetry with b.decode().
Do we actually need b.decode()?
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
> Adding data locking shouldn't be too complicated, but is it necessary?
> The bytes object does support locking the buffer in place; isn't that
> enough? It means someone evil could still produce a phase error by
> changing the contents while you're looking at it (basically sabotaging
> their own
On Aug 27, 2007, at 6:16 PM, [EMAIL PROTECTED] wrote:
> I would like to see PEP 8 remove the "as necessary to improve
> readability" in the function and method naming conventions.
That would leave a whole bunch of built-in stuff
non-conforming with PEP 8, though...
--
Greg
43 matches
Mail list logo
