Re: [Python-Dev] core python tests
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 moved off to SIGs there won't be anything left for python-dev to talk about ;) There is already an stdlib-sig, which has been almost unused. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 be interested in contributing to? As performance moves more into the wider consciousness, having good tools will become increasingly important. GSoC work? -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 problems and offers more - precise measurements. Is that something you might be interested in - contributing to? As performance moves more into the wider - consciousness, having good tools will become increasingly important. - - GSoC work? Alas, it's too late to submit new proposals; the deadline was yesterday. The next Google gives us money to wrangle students into doing development project will probably be GHOP for highschool students, in the winter, although it has not been announced and may not happen. cheers, --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] core python tests
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. If too many things get moved off to SIGs there won't be anything left for python-dev to talk about ;) There is already an stdlib-sig, which has been almost unused. stdlib-sig isn't *quite* right (the testing and benchmarking are as much about core python as the stdlib) - although we could view the benchmarks and tests themselves as part of the standard library... Either way we should get it underway. Collin and Jeffrey - happy to use stdlib-sig? Michael Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 PEP? (The proximal issue is whether or not this is of direct relevance to the python core and hence should be given priority.) tnx, -titus Rene Dudfield wrote: - there's seven graphics math type proposals which would be a good project - for the graphics python using projects -- especially if they can get - into python. - - It would be great if one of these proposals was accepted to work towards - getting these simple types into python. - - 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 have interoperability issues. - - The reason why just these basic types, and not full blown numpy is that - numpy is never planned to get into python. Numpy doesn't want to tie - it's development into pythons development cycle. Whereas a small set of - types can be implemented and stabalised for python more easily. - - Also, it's not image, or 3d format types -- since those are also a way - larger project. -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
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 have interoperability issues. This interoperability problem is the very reason the new buffer API and memoryview object were devised by Travis Oliphant (who is, AFAIK, a numpy contributor). Unfortunately, Travis disappeared and left us with an unfinished implementation which doesn't support anything else than linear byte buffers. So, rather than trying to stuff new specialized datatypes into Python, I suggest maths types proponents contribute the missing bits of the new buffer API and memoryview object :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 voice your opinion. http://wiki.python.org/moin/CoreDevHelperTools Some of the tools/extensions categories that could be relevant: - Wrappers for working with tracker issues - Wrapper for managing patches - Wrapper for running tests - Wrapper for submitting diffs for review - Commit helpers (various hooks) - Various Roundup extensions Please be invited to comment and raise your concerns, so we could discuss them together and make our hacker's life more enjoyable. My name is Mario Đanić, a hopeful GSoC student, and I am looking forward working with you. Thank you for your time and your help in this matter. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] core python tests
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. It probably belongs at python.org but if you want me to host it, I can. If too many things get moved off to SIGs there won't be anything left for python-dev to talk about ;) There is already an stdlib-sig, which has been almost unused. stdlib-sig isn't *quite* right (the testing and benchmarking are as much about core python as the stdlib) - although we could view the benchmarks and tests themselves as part of the standard library... Either way we should get it underway. Collin and Jeffrey - happy to use stdlib-sig? Works for me. Collin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 solip...@pitrou.net wrote: 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 have interoperability issues. This interoperability problem is the very reason the new buffer API and memoryview object were devised by Travis Oliphant (who is, AFAIK, a numpy contributor). Unfortunately, Travis disappeared and left us with an unfinished implementation which doesn't support anything else than linear byte buffers. So, rather than trying to stuff new specialized datatypes into Python, I suggest maths types proponents contribute the missing bits of the new buffer API and memoryview object :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 this from the new SIG page. http://wiki.python.org/moin/Special%20Interest%20Groups Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdelonEjvBPtnXfVAQI0QQP/c0mXr4OA+yLOFHqSksFxT5pkt2xPtxPO 25VfcGFmP0FydsGMW0fpIPC9nw3kaZhtwtx5iYiRXOg796IParSzSdleKwRdabwA SH+EzhD0gprwyfPEi6Vptb+ORz8if1gz4UPIUBfJaLVGw7eXH0Xue5rqUEksu6MX wi/MMub9V0g= =2FHl -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] core python tests
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: 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 moved off to SIGs there won't be anything left for python-dev to talk about ;) There is already an stdlib-sig, which has been almost unused. stdlib-sig isn't *quite* right (the testing and benchmarking are as much about core python as the stdlib) - although we could view the benchmarks and tests themselves as part of the standard library... Either way we should get it underway. Collin and Jeffrey - happy to use stdlib-sig? Works for me. Me too. bcc python-dev, - stdlib-sig First question: Do people want the unladen-swallow performance tests in the CPython repository until the whole library gets moved out? If so, where? Tools/performance? Lib/test/benchmarks? I'm +1 on including them (so long as they run under trunk of course) but agnostic on location. Maybe better not in test as it might be expected that a full regrtest would then run them? I'm keeping Python-dev cc'd as it is a Python-dev decision and bcc messages require individual admin approval. Michael Jeffrey -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 operations on objects that support the new buffer protocol. Together with a multidimensional version of the standard array.array type, this would provide a kind of numpy lite that you could use to build reasonably efficient vector and matrix types with no external dependencies. By making these functions that operate through the buffer protocol rather than special types, they would be much more flexible and interoperate with other libraries very well. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
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 would provide a kind of numpy lite that you could use to build reasonably efficient vector and matrix types with no external dependencies. 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. Interested people should start with this, before jumping to the higher-level stuff. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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(_FileIO):
def close(self):
# do close
_FileIO.close(self)
This means that, if a subclass overrides flush(), it will be called after
the file has been closed e.g.
import io
class MyIO(io.FileIO):
... def flush(self):
... print('closed:', self.closed)
...
f = MyIO('test.out', 'wb')
f.close()
closed: True
It seems to me that, during close, calls should only propagate up the
class hierarchy i.e.
class _FileIO(object):
def flush(self):
if self.__IOBase_closed:
raise ...
def close(self):
_FileIO.flush(self)
self.__IOBase_closed = True
I volunteer to change this if there is agreement that this is the way to go.
Cheers,
Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 include an ordered dictionary implementation and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/dev/py3k/whatsnew/3.1.html or Misc/NEWS in the Python distribution. Please note that this is an alpha releases, and as such is not suitable for production environments. We continue to strive for a high degree of quality, but there are still some known problems and the feature sets have not been finalized. This alpha is being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 3.1 might impact you. If you find things broken or incorrect, please submit a bug report at http://bugs.python.org For more information and downloadable distributions, see the Python 3.1 website: http://www.python.org/download/releases/3.1/ See PEP 375 for release schedule details: http://www.python.org/dev/peps/pep-0375/ Regards, -- Benjamin Benjamin Peterson benjamin at python.org Release Manager (on behalf of the entire python-dev team and 3.1's contributors) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible py3k io wierdness
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 _pyio.py does the same thing: def close(self) - None: Flush and close the IO object. This method has no effect if the file is already closed. if not self.__closed: try: self.flush() except IOError: pass # If flush() fails, just give up self.__closed = True Note how it calls `self.flush()` and not `IOBase.flush(self)`. When writing the C version of the I/O stack, we tried to keep the semantics the same as in the Python version, although there are a couple of subtleties. Your problem here is that it's IOBase.close() which calls your flush() method, but FileIO.close() has already done its job before and the internal file descriptor has been closed (hence `self.closed` is True). In this particular case, I advocate overriding close() as well and call your flush() method manually from there. Thanks for your feedback! Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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: http://sources.redhat.com/cygwin-apps/setup.html Ah, ok. It has the big disadvantage of not being Microsoft-endorsed, though. In that sense, it feels very much like easy_install (which also does dependencies). Not only that, but the Cygwin packaging system appears to be extremely difficult to organize a package for. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
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 just hasn't been tested very well? No, only simple linear bytes are supported. If so, writing some things that attempt to use it in non-trivial ways would be a useful thing to do. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
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 the memoryview object? 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 (e.g. memoryview.tolist()). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 letting you do that (although I do wonder who would then be in charge of the Mercurial installation in the long run, the way I have been in charge of the subversion installation). To proceed, I think the next step should be to discuss in the PEP the details of the migration procedure (see PEP 347 for what level of detail I produced for the svn migration), and to set up a demo installation that is considered ready-to-run, except that it might get torn down again, if the actual conversion requires that (it did for the CVS-svn case), or if problems are found with the demo installation. I would personally remove all non-mercurial stuff out of PEP 374, and retitle it, but that would be your choice. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 some things that attempt to use it in non-trivial ways would be a useful thing to do. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
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 collections of bytes. (I have added tests for arrays in test_memoryview, but that's all. And that's only in py3k since array.array in 2.x only supports the old buffer interface) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 the implementation so that the argument to peek() becomes the upper bound to the number of bytes returned? Thanks for your advice, Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UnicodeDecodeError bug in distutils
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 register and write_pkg_info() accepted 8-bit strings and passed them on as-is, so the only workaround for this issue at the moment is to revert to Python 2.4 or less. What is the prognosis on this issue? It's still hitting me in Python 2.5.4. Any word on this? Is there an open bug tracker issue with more information? Who's working on this? -- \ “If sharing a thing in no way diminishes it, it is not rightly | `\ owned if it is not shared.” —Saint Augustine | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BufferedReader.peek() ignores its argument
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 bit strange and unhelpful though. Should we change the implementation so that the argument to peek() becomes the upper bound to the number of bytes returned? +1 That sounds more useful. Thanks for your advice, -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 only workaround for this issue at the moment is to revert to Python 2.4 or less. What is the prognosis on this issue? It's still hitting me in Python 2.5.4. Any word on this? Is there an open bug tracker issue with more information? Who's working on this? For Python 2.5.4, no further changes will be made. If you can reproduce with 2.6, and can't find a tracker issue, make a new report. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 a shame to throw it away when it may become in handy for other FOSS projects that want to move away from subversion. 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. Dirkjan or whoever is going to work on the PEP can copy n' paste the interesting pieces from PEP 374 to the new one. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 bit strange and unhelpful though. Should we change the implementation so that the argument to peek() becomes the upper bound to the number of bytes returned? IIRC, this was made to handle SSL where the number of bytes returned may need to be larger than the size. If that's the case, there should be a record somewhere in the list archives... (Or possibly the svn logs.) -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UnicodeDecodeError bug in distutils
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 can know whether it's resolved. -- \“The World is not dangerous because of those who do harm but | `\ because of those who look at it without doing anything.” | _o__) —Albert Einstein | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 wiki page would also allow referring to it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 and made difficult to access. To keep it online, it doesn't have to be in the PEP - putting it in a wiki page would also allow referring to it. Sure. A title like DvcsComparison would be easy to remember. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
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 relative to 3.1 final and 2.7 final. I am willing to take over this. I was in charge of the Mercurial scenarios in the PEP, so it would be natural for me to continue with the transition. In addition, I volunteer to maintain the new Mercurial installation. Off the top of my head, the following is needed for a successful migration: - Verify that the repository at http://code.python.org/hg/ is properly converted. - Convert the current svn commit hooks to Mercurial. - Add Mercurial support to the issue tracker. - Update the developer FAQ. - Setup temporary svn mirrors for the main Mercurial repositories. - Augment code.python.org infrastructure to support the creation of developer accounts. - Update the release.py script. There is probably some other things that I missed, but I think this is a good overview of what needs to be done. And of course, I would welcome anyone who would be willing to help me with the transition. -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
