Another thing that needs to be ported are the changes to
Lib/test/regrtest.py. Pretty much anything that references ABCs in
there needs backporting. You can verify it works properly by running
regrtest.py with the -R option on any test that uses an ABC. It
should not report leaks. The full comm
No problem. Created issue 1026 in tracker with a single patch file attached.
I'm not aware of what changes need to be done with _abcoll.py and
collections.py. If you can point me to the right direction, I would
definitely like to work on it.
On 8/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrot
On 8/26/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> On 8/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> > Gregory P. Smith wrote:
> > > I'm in favor of not allowing unicode for hash functions. Depending on
> > > the system default encoding for a hash will not be portable.
> > >
> > > an
On 8/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
> Gregory P. Smith wrote:
> > I'm in favor of not allowing unicode for hash functions. Depending on
> > the system default encoding for a hash will not be portable.
> >
> > another question for hashlib: It uses PyArg_Parse to get a single '
On 8/26/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
> > I'm in favor of not allowing unicode for hash functions. Depending on
> > the system default encoding for a hash will not be portable.
> >
> > another question for hashlib: It uses PyArg_Parse to get a single 's'
On 8/26/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
> It would be useful to support 'newline' and 'encoding' arguments in
> tempfile.TemporaryFile and friends. These new arguments would be
> passed directly into io.open. I've uploaded a patch for this to:
>
> http://bugs.python.org/issue1033
>
> The
Gregory P. Smith wrote:
> I'm in favor of not allowing unicode for hash functions. Depending on
> the system default encoding for a hash will not be portable.
>
> another question for hashlib: It uses PyArg_Parse to get a single 's'
> out of an optional parameter [see the code] and I couldn't fi
It would be useful to support 'newline' and 'encoding' arguments in
tempfile.TemporaryFile and friends. These new arguments would be
passed directly into io.open. I've uploaded a patch for this to:
http://bugs.python.org/issue1033
The 'bufsize' argument to os.fdopen has changed to 'buffering' s
I'm in favor of not allowing unicode for hash functions. Depending on
the system default encoding for a hash will not be portable.
another question for hashlib: It uses PyArg_Parse to get a single 's'
out of an optional parameter [see the code] and I couldn't figure out
what the best thing to do
On Sunday 26 August 2007 23:23:37 Amaury Forgeot d'Arc wrote:
> internal_close(PyFileIOObject *self)
> {
> int save_errno = 0;
> - if (self->fd >= 0) {
> + if (self->fd >= 3) {
> int fd = self->fd;
> self->fd = -1;
> Py_BEGIN_ALL
On 8/26/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Hello,
>
> It seems that the new I/O system closes the 3 standard descriptors
> (stdin, stdout and stderr) when the sys module is unloaded.
Amaury,
Other than this problem, can you report on how py3k is working on
Windows? How did you
Hello,
It seems that the new I/O system closes the 3 standard descriptors
(stdin, stdout and stderr) when the sys module is unloaded.
I don't know if it is a good thing on Unix, but on Windows at least,
python crashes on exit, when call_ll_exitfuncs calls fflush(stdout)
and fflush(stderr).
As a
On 8/25/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 8/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 2. I noticed a couple places where it seems to replace "if isinstance"
> >with "ifinstance". Seems like an output bug of some sort.
>
> That bug was probably me. I did so
Change r57490 by Gregory P Smith broke a test in test_unicodedata and,
on PPC OSX, several tests in test_hashlib.
Looking into this it's pretty clear *why* it broke: before, the 's#'
format code was used, while Gregory's change changed this into using
the buffer API (to ensure the data won't move
> These are very good points, and fit exactly with my experience. For my
> personal use, I happily install and use any package that helps. For
> deployment, however, I very rarely contemplate relying on anything
> other than "the essentials" (to me, that covers Python, pywin32, and
> cx_Oracle - th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 25, 2007, at 2:10 AM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>
>> I've been spending hours of my own time on the email package for py3k
>> this week and every time I think I'm nearing success I get defeated
>> again.
>
> I'm ankle de
On 8/25/07, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Take for example GUI packages. Tkinter is far from ideal, but there
> are many competitors, none of them perfect (not even those packages
> specifically designed to be platform-neutral). We can't very well
> include all of the major packag
Sorry. Forgot to change the subject
-- Original message --
From: [EMAIL PROTECTED]
> On 8/25/07, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > Take for example GUI packages. Tkinter is far from ideal, but there
> > are many competitors, none of them perfect (n
I got it now. both modules need to be backported as well. I'm on it.
On 8/26/07, Benjamin Aranguren <[EMAIL PROTECTED]> wrote:
> No problem. Created issue 1026 in tracker with a single patch file attached.
>
> I'm not aware of what changes need to be done with _abcoll.py and
> collections.py.
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 "batteries" would be
included as part of the final Python r
We copied abc.py and test_abc.py from py3k svn and modified to work with 2.6.
After making all the changes we ran all the tests to ensure that no
other modules were affected.
Attached are abc.py, test_abc.py, and their relevant patches from 3.0 to 2.6.
On 8/25/07, Guido van Rossum <[EMAIL PROTEC
Thanks!
Would it inconvenience you terribly to upload this all to the new
tracker (bugs.python.org)? Preferably as a single patch against the
svn trunk (to use svn diff, you have to svn add the new files first!)
Also, are you planning to work on _abcoll.py and the changes to collections.py?
--Gu
On 8/26/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Another possibility (which I personally favor) is to leave the email
> package in a1 as flawed as it is, but to disable the tests. It's an /
> alpha/ for gosh sakes, so maybe leaving it in and partly broken will
> help rustle up some volunteers
On Sun, Aug 26, 2007, [EMAIL PROTECTED] wrote:
>
> aahz> Please don't interpret a missing chorus of opposition as support.
> aahz> I'm only -0, but I definitely am negative on the idea based on my
> aahz> guess about the likelihood of problems.
>
> -0 on the idea of more batteries or
On 26/08/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 26, 2007, at 12:10 AM, 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 provi
-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
aahz> Please don't interpret a missing chorus of opposition as support.
aahz> I'm only -0, but I definitely am negative on the idea based on my
aahz> guess about the likelihood of problems.
-0 on the idea of more batteries or fewer batteries?
Skip
28 matches
Mail list logo
