Nick Coghlan ncoghlan at 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
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 be
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 problems and
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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.
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
C. Titus Brown ctb at 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 to
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)
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
On Sat, Apr 4, 2009 at 7:33 AM, Michael Foord fuzzy...@voidspace.org.uk wrote:
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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.
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 solip...@pitrou.net wrote:
C. Titus Brown ctb at
-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
Jeffrey Yasskin wrote:
On Sat, Apr 4, 2009 at 11:52 AM, Collin Winter coll...@gmail.com wrote:
On Sat, Apr 4, 2009 at 7:33 AM, Michael Foord fuzzy...@voidspace.org.uk wrote:
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at gmail.com writes:
C. Titus Brown wrote:
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
Greg Ewing greg.ewing at 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
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
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
Hi!
brian at 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
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: http://sources.redhat.com/cygwin-apps/setup.html
Ah, ok. It has the big disadvantage of not being
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
___
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
2009/4/4 Greg Ewing greg.ew...@canterbury.ac.nz:
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
Greg Ewing greg.ewing at 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
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
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
Greg Ewing greg.ewing at 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
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
Ben Finney ben+pyt...@benfinney.id.au writes:
Phillip J. Eby p...@telecommunity.com 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
2009/4/4 Antoine Pitrou solip...@pitrou.net:
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
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 only
workaround
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
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 bit
Ben Finney ben+pyt...@benfinney.id.au writes:
Is there an open bug tracker issue with more information?
Answer: URL:http://bugs.python.org/issue2562. Apparently the issue
is resolved URL:http://bugs.python.org/msg72385 for Python 2.6. I
will need to wait for my distribution to catch up before I
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
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
On Sat, Apr 4, 2009 at 11:40 AM, Aahz a...@pythoncraft.com 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
35 matches
Mail list logo
