[Python-Dev] Should I/O object wrappers close their underlying buffer when deleted?

Hello, I would like to call to your attention the following behavior of TextIOWrapper: import io def test(buf): textio = io.TextIOWrapper(buf) buf = io.BytesIO() test(buf) print(buf.closed) # This prints True currently The problem here is TextIOWrapper closes its buffer whe

Re: [Python-Dev] BufferedReader.peek() ignores its argument

On Sat, Apr 4, 2009 at 9:03 PM, Antoine Pitrou wrote: > Hello, > > Currently, BufferedReader.peek() ignores its argument and can return more or > less than the number of bytes requested by the user. This is how it was > implemented in the Python version, and we've reflected this in the C version.

Re: [Python-Dev] Mercurial?

On Sat, Apr 4, 2009 at 11:40 AM, Aahz wrote: > With Brett's (hopefully temporary!) absence, who is spearheading the > Mercurial conversion?  Whoever it is should probably take over PEP 374 > and start updating it with the conversion plan, particularly WRT > expectations for dates relative to 3.1 f

Re: [Python-Dev] Mercurial?

Martin v. Löwis wrote: I second not tossing the data and history. It serves as partial justification for the decision, which has been and will occasionally again be discussed on python-list. It's in subversion, so the history won't be tossed. I know; I should have been more exact: not hidden

Re: [Python-Dev] Mercurial?

> I second not tossing the data and history. It serves as partial > justification for the decision, which has been and will occasionally > again be discussed on python-list. It's in subversion, so the history won't be tossed. To keep it online, it doesn't have to be in the PEP - putting it in a w

Re: [Python-Dev] UnicodeDecodeError bug in distutils

Ben Finney writes: > Is there an open bug tracker issue with more information? Answer: http://bugs.python.org/issue2562>. Apparently the issue is resolved http://bugs.python.org/msg72385> for Python 2.6. I will need to wait for my distribution to catch up before I can know whether it's resolved.

Re: [Python-Dev] BufferedReader.peek() ignores its argument

On Sun, Apr 05, 2009, Antoine Pitrou wrote: > > Currently, BufferedReader.peek() ignores its argument and can return > more or less than the number of bytes requested by the user. This is > how it was implemented in the Python version, and we've reflected this > in the C version. > > It seems a bi

Re: [Python-Dev] Mercurial?

Christian Heimes wrote: Martin v. Löwis wrote: I would personally remove all non-mercurial stuff out of PEP 374, and retitle it, but that would be your choice. I suggest we keep the old PEP and start a new one about Hg exclusively. The original PEP 374 has cost Brett a lot of time. It would be

Re: [Python-Dev] UnicodeDecodeError bug in distutils

>>> Meanwhile, the 'register' command accepts Unicode, but is broken in >>> handling it. […] >>> >>> Unfortunately, this isn't fixable until there's a new 2.5.x release. >>> For previous Python versions, both register and write_pkg_info() >>> accepted 8-bit strings and passed them on as-is, so the

Re: [Python-Dev] Mercurial?

Martin v. Löwis wrote: > I would personally remove all non-mercurial stuff out of PEP 374, > and retitle it, but that would be your choice. I suggest we keep the old PEP and start a new one about Hg exclusively. The original PEP 374 has cost Brett a lot of time. It would be a shame to throw it awa

Re: [Python-Dev] BufferedReader.peek() ignores its argument

2009/4/4 Antoine Pitrou : > Hello, > > Currently, BufferedReader.peek() ignores its argument and can return more or > less than the number of bytes requested by the user. This is how it was > implemented in the Python version, and we've reflected this in the C version. > > It seems a bit strange an

Re: [Python-Dev] UnicodeDecodeError bug in distutils

Ben Finney writes: > "Phillip J. Eby" writes: > > > Meanwhile, the 'register' command accepts Unicode, but is broken in > > handling it. […] > > > > Unfortunately, this isn't fixable until there's a new 2.5.x release. > > For previous Python versions, both register and write_pkg_info() > > acc

[Python-Dev] BufferedReader.peek() ignores its argument

Hello, Currently, BufferedReader.peek() ignores its argument and can return more or less than the number of bytes requested by the user. This is how it was implemented in the Python version, and we've reflected this in the C version. It seems a bit strange and unhelpful though. Should we change t

Re: [Python-Dev] Mercurial?

> I'd like to take that on. I know hardly anyone here knows me, but I'm > one of the Mercurial developers. I've been in contact with Brett, saying > that I'd gladly as much help as I could, and I figured I'd put a lot of > time in providing the best possible migration path. I'm personally happy le

Re: [Python-Dev] graphics maths types in python core?

Greg Ewing canterbury.ac.nz> writes: > > > Again, I don't want to spoil the party, but multidimensional buffers are > > not implemented, and neither are buffers of anything other than single-byte > > data. > > When you say "buffer" here, are you talking about the > buffer interface itself, or th

Re: [Python-Dev] graphics maths types in python core?

2009/4/4 Greg Ewing : > Antoine Pitrou wrote: > >> Both. >> Well, taking a buffer or memoryview to non-bytes data is supported, but >> since >> it's basically unused, some things are likely missing or broken > > So you're saying the buffer interface *has* been fully > implemented, it just hasn't be

Re: [Python-Dev] graphics maths types in python core?

Greg Ewing canterbury.ac.nz> writes: > > So you're saying the buffer interface *has* been fully > implemented, it just hasn't been tested very well? No, it hasn't been implemented for multi-dimensional types, and it hasn't been really tested for anything other than plain linear collections of by

Re: [Python-Dev] graphics maths types in python core?

Antoine Pitrou wrote: Both. Well, taking a buffer or memoryview to non-bytes data is supported, but since it's basically unused, some things are likely missing or broken So you're saying the buffer interface *has* been fully implemented, it just hasn't been tested very well? If so, writing so

Re: [Python-Dev] graphics maths types in python core?

Antoine Pitrou wrote: Again, I don't want to spoil the party, but multidimensional buffers are not implemented, and neither are buffers of anything other than single-byte data. When you say "buffer" here, are you talking about the buffer interface itself, or the memoryview object? -- Greg ___

[Python-Dev] 3.1 beta is closer than you think

3.1's only beta is planned for May 2nd, so that means you have exactly 28 days to get the amazing 3.1 features you have planned checked into the py3k branch. There will be absolutely no new features after the beta is released. -- Regards, Benjamin ___ P

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

Martin v. Löwis wrote: >> That's not entirely true; Cygwin comes with a package management tool >> that probably could be used to set up a repository of python packages >> for native Windows: > > Ah, ok. It has the big disadvantage of not being Mi

Re: [Python-Dev] Possible py3k io wierdness

Hi! sweetapp.com> writes: > > class _RawIOBase(_FileIO): FileIO is a subclass of _RawIOBase, not the reverse: >>> issubclass(_io._RawIOBase, _io.FileIO) False >>> issubclass(_io.FileIO, _io._RawIOBase) True I do understand your surprise, but the Python implementation of IOBase.close() in _pyi

[Python-Dev] [RELEASED] Python 3.1 alpha 2

On behalf of the Python development team, I'm thrilled to announce the second alpha release of Python 3.1. Python 3.1 focuses on the stabilization and optimization of features and changes Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. Other features inc

[Python-Dev] Possible py3k io wierdness

Hey, I noticed that the call pattern of the C-implemented io libraries is as follows (translating from C to Python): class _FileIO(object): def flush(self): if self.__IOBase_closed: raise ... def close(self): self.flush() self.__IOBase_closed = True class _RawIOBase(_FileI

Re: [Python-Dev] graphics maths types in python core?

Greg Ewing canterbury.ac.nz> writes: > > Something I've suggested before is to provide a set of > functions for doing elementwise arithmetic operations on > objects that support the new buffer protocol. > > Together with a multidimensional version of the standard > array.array type, this would p

Re: [Python-Dev] graphics maths types in python core?

C. Titus Brown wrote: we're having a discussion over on the GSoC mailing list about basic math types, and I was wondering if there is any history that we should be aware of in python-dev. Something I've suggested before is to provide a set of functions for doing elementwise arithmetic operatio

Re: [Python-Dev] Mercurial?

On 04/04/2009 17:40, Aahz wrote: With Brett's (hopefully temporary!) absence, who is spearheading the Mercurial conversion? Whoever it is should probably take over PEP 374 and start updating it with the conversion plan, particularly WRT expectations for dates relative to 3.1 final and 2.7 final.

Re: [Python-Dev] core python tests

Jeffrey Yasskin wrote: On Sat, Apr 4, 2009 at 11:52 AM, Collin Winter wrote: On Sat, Apr 4, 2009 at 7:33 AM, Michael Foord wrote: Antoine Pitrou wrote: Nick Coghlan gmail.com> writes: C. Titus Brown wrote: I vote for a separate mailing list -- 'python-

Re: [Python-Dev] Package Management - thoughts from the peanut gallery

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 3, 2009, at 4:01 AM, Tarek Ziadé wrote: Each one of this task has a leader, except the one with (*). I just got back from travelling, and I will reorganize http://wiki.python.org/moin/Distutils asap to it is up-to-date. I added a link to

Re: [Python-Dev] graphics maths types in python core?

I'm not even sure what you mean by "basic math types" (it would probably depend on which math curriculum you are using :-) but if you're not already aware of PEP 3141, that's where to start. --Guido On Sat, Apr 4, 2009 at 8:09 AM, Antoine Pitrou wrote: > C. Titus Brown msu.edu> writes: >> >> we

Re: [Python-Dev] core python tests

On Sat, Apr 4, 2009 at 7:33 AM, Michael Foord wrote: > Antoine Pitrou wrote: >> >> Nick Coghlan gmail.com> writes: >> >>> >>> C. Titus Brown wrote: >>> I vote for a separate mailing list -- 'python-tests'? -- but I don't know exactly how splintered to make the conversation.  It pro

[Python-Dev] Helper Python core development tools

With all the sand and sun on the beaches, should I really be doing this now? That is the question we probably ask ourselves every time we have to do some boring task. What kind of things do you think could be made better? What would make your workflow smoother and more fun? Now is your chance to v

[Python-Dev] Mercurial?

With Brett's (hopefully temporary!) absence, who is spearheading the Mercurial conversion? Whoever it is should probably take over PEP 374 and start updating it with the conversion plan, particularly WRT expectations for dates relative to 3.1 final and 2.7 final. -- Aahz (a...@pythoncraft.com)

Re: [Python-Dev] graphics maths types in python core?

C. Titus Brown msu.edu> writes: > > we're having a discussion over on the GSoC mailing list about basic > math types > [...] > -> > -> Otherwise we'll be doomed to have each project implement vec2, vec3, > -> vec4, matrix3/4, quaternion (which has already happened many times) - > -> and continue

[Python-Dev] graphics maths types in python core?

Hi all, we're having a discussion over on the GSoC mailing list about basic math types, and I was wondering if there is any history that we should be aware of in python-dev. Has this been brought up before and rejected? Should the interested projects work towards a consensus and maybe write up a

Re: [Python-Dev] core python tests

Antoine Pitrou wrote: Nick Coghlan gmail.com> writes: C. Titus Brown wrote: I vote for a separate mailing list -- 'python-tests'? -- but I don't know exactly how splintered to make the conversation. It probably belongs at python.org but if you want me to host it, I can. If too

[Python-Dev] GSoC (was Re: PyDict_SetItem hook)

On Sat, Apr 04, 2009 at 06:28:01AM -0700, Aahz wrote: -> On Fri, Apr 03, 2009, Collin Winter wrote: -> > -> > I don't believe that these are insurmountable problems, though. A -> > great contribution to Python performance work would be an improved -> > version of PyBench that corrects these problem

Re: [Python-Dev] PyDict_SetItem hook

On Fri, Apr 03, 2009, Collin Winter wrote: > > I don't believe that these are insurmountable problems, though. A > great contribution to Python performance work would be an improved > version of PyBench that corrects these problems and offers more > precise measurements. Is that something you might

Re: [Python-Dev] core python tests

Nick Coghlan gmail.com> writes: > > C. Titus Brown wrote: > > I vote for a separate mailing list -- 'python-tests'? -- but I don't > > know exactly how splintered to make the conversation. It probably > > belongs at python.org but if you want me to host it, I can. > > If too many things get mov