Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)

On 3 Jun, 07:08 pm, mar...@v.loewis.de wrote: To go back to JP's original comments though: what was the right thing for him to do, back in January, when he had these concerns? To me, it's fairly clear: what the committer needs to get is guidance in any action to take. In most cases, the set

Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)

On 05:42 pm, p.f.mo...@gmail.com wrote: 2009/6/3 : So, here are my recommendations:  1. Use the tracker for discussing tickets, so that it's easy to refer back to a previous point in the discussion, and so that people working on those tickets can easily find your commentary.  2. Use the ma

Re: [Python-Dev] Issues with Py3.1's new ipaddr

On 05:19 pm, gu...@python.org wrote: On Wed, Jun 3, 2009 at 10:13 AM, Neil Schemenauer wrote: Barry Warsaw wrote: It would be really nice if say the Cheeseshop had a voting feature. Use PEP 10 voting to get a rough estimate of a module's popularity (download counts alone might not tell you ev

Re: [Python-Dev] Issues with Py3.1's new ipaddr

On 07:51 am, p.f.mo...@gmail.com wrote: 2009/6/3 Stephen J. Turnbull : One thing I would recommend is that while inclusion is not a matter of voting, people who are recognized as domain experts on Python-Dev *should* try to add their "+1" or "-1" early. �Especially if they don't expect to have

Re: [Python-Dev] Issues with Py3.1's new ipaddr

On 02:44 am, a...@pythoncraft.com wrote: On Tue, Jun 02, 2009, Guido van Rossum wrote: I hope we can learn from this. I'm not thrilled with adding more process just because we had a problem here, and the only obvious solution I see is to require a PEP every time a module is added. Based on

[Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)

On 02:39 am, gu...@python.org wrote: I'm disappointed in the process -- it's as if nobody really reviewed the API until it was released with rc1, and this despite there being a significant discussion about its inclusion and alternatives months ago. (Don't look at me -- I wouldn't recognize a net

Re: [Python-Dev] question about docstring formatting

On 01:06 pm, jer...@alum.mit.edu wrote: It says that the summary line may be used by automatic indexing tools, but is there any evidence that such a tool actually exists? Or was there once upon a time? If there are no such tools, do we still think that it is important that it fits on line line

Re: [Python-Dev] a suggestion ... Re: PEP 383 (again)

On 04:07 pm, mar...@v.loewis.de wrote: Martin, if you're going to stick with the half-surrogate trick, would you mind adding a section to the PEP on "alternate encoding strategies", explaining why the NULL method was not selected? In the PEP process, it isn't my job to criticize competing pr

Re: [Python-Dev] a suggestion ... Re: PEP 383 (again)

On 03:35 pm, mar...@v.loewis.de wrote: So, why do you prefer half surrogate coding to U+ quoting? If I pass a string with an embedded U+ to gtk, gtk will truncate the string, and stop rendering it at this character. This is worse than what it does for invalid UTF-8 sequences. Chances ar

Re: [Python-Dev] a suggestion ... Re: PEP 383 (again)

On 02:42 pm, tmb...@gmail.com wrote: So, why do you prefer half surrogate coding to U+ quoting? I have also been eagerly waiting for an answer to this question. I am afraid I have lost it somewhere in the storm of this thread :). Martin, if you're going to stick with the half-surrogate

Re: [Python-Dev] a suggestion ... Re: PEP 383 (again)

On 08:25 am, mar...@v.loewis.de wrote: Why did you choose an incompatible approach for PEP 383? Because in Python, we want to be able to access all files on disk. Neither Java nor Mono are capable of doing that. Java is not capable of doing that. Mono, as I keep pointing out, is. It uses N

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

On 07:17 pm, mar...@v.loewis.de wrote: -1. On UNIX, character data is not sufficient to represent paths. We must, must, must continue to have a simple bytes interface to these APIs. I'd like to respond to this concern in three ways: 1. The PEP doesn't remove any of the existing interfaces.

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

On 06:50 am, mar...@v.loewis.de wrote: I'm proposing the following PEP for inclusion into Python 3.1. Please comment. To convert non-decodable bytes, a new error handler "python-escape" is introduced, which decodes non-decodable bytes using into a private-use character U+F01xx, which is believ

Re: [Python-Dev] PEP 382: Namespace Packages

On 04:56 am, p...@telecommunity.com wrote: At 03:58 AM 4/17/2009 +, gl...@divmod.com wrote: Just as a use-case: would the Java "com.*" namespace be an example of a "pure package with no base"? i.e. lots of projects are in it, but no project owns it? Er, I suppose. I was thinking more of

Re: [Python-Dev] PEP 382: Namespace Packages

On 16 Apr, 03:36 pm, p...@telecommunity.com wrote: At 03:46 AM 4/16/2009 +, gl...@divmod.com wrote: On 15 Apr, 09:11 pm, p...@telecommunity.com wrote: Twisted has its own system for "namespace" packages, and I'm not really sure where we fall in this discussion. I haven't been able to fo

Re: [Python-Dev] Issue5434: datetime.monthdelta

On 16 Apr, 11:11 pm, f...@fuhm.net wrote: On Apr 16, 2009, at 5:47 PM, Antoine Pitrou wrote: It's a human-interface operation, and as such, everyone (ahem) "knows what it means" to say "2 months from now", but the details don't usually have to be thought about too much. Of course when you ha

Re: [Python-Dev] PEP 382: Namespace Packages

On 15 Apr, 09:11 pm, p...@telecommunity.com wrote: I think that there is some confusion here. A "main" package or buildout that assembles a larger project from components is not the same thing as having a "base" package for a namespace package. I'm certainly confused. Twisted has its own sy

Re: [Python-Dev] Dropping bytes "support" in json

On 03:21 am, ncogh...@gmail.com wrote: Barry Warsaw wrote: I don't know whether the parameter thing will work or not, but you're probably right that we need to get the bytes-everywhere API first. Given that json is a wire protocol, that sounds like the right approach for json as well. Once

Re: [Python-Dev] Dropping bytes "support" in json

On 02:38 am, ba...@python.org wrote: So, what I'm really asking is this. Let's say you agree that there are use cases for accessing a header value as either the raw encoded bytes or the decoded unicode. What should this return: >>> message['Subject'] The raw bytes or the decoded unicode?

[Python-Dev] the email module, text, and bytes (was Re: Dropping bytes "support" in json)

On 02:26 am, ba...@python.org wrote: There are really two ways to look at an email message. It's either an unstructured blob of bytes, or it's a structured tree of objects. Those objects have headers and payload. The payload can be of any type, though I think it generally breaks down into "s

Re: [Python-Dev] PEP 382: Namespace Packages

On 08:15 pm, mar...@v.loewis.de wrote: Note that there is no such thing as a "defining namespace package" -- namespace package contents are symmetrical peers. With the PEP, a "defining package" becomes possible - at most one portion can define an __init__.py. For what it's worth, this is a _s

[Python-Dev] splitting out bdist_* (was: interminable 'setuptools' thread)

On 07:59 pm, fdr...@acm.org wrote: I'm actually in favor of removing the bdist_* from the standard library, and allowing 3rd-party tools to implement whatever they need for the distros. But I don't think what you're presenting there supports it. I do think that it's relevant that the respec

Re: [Python-Dev] "setuptools has divided the Python community"

On 26 Mar, 07:22 pm, ba...@python.org wrote: One thing that /would/ be helpful though is the ability to list all the resources under a specific package path. This is (I think) one use case that pkg_resource fails to support and it's the one place that I've had to drop down to file system intro

Re: [Python-Dev] PEP 377 - allow __enter__() methods to skip the statement body

On 12:56 pm, ncogh...@gmail.com wrote: PEP 377 is a proposal to allow context manager __enter__() methods to skip the body of the with statement by raising a specific (new) flow control exception. Since there is a working reference implementation now, I thought it was time to open it up for bro

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 02:46 pm, dan...@stutzbachenterprises.com wrote: On Sat, Mar 7, 2009 at 8:28 PM, wrote: Anybody interested in working on this at a PyCon Sprint? I won't be attending the conference proper, but plan to spend a couple days sprinting, I'll be there and interested. :) Great! I plan to ho

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 01:50 am, n...@arctrix.com wrote: gl...@divmod.com wrote: we're not even talking about actually putting any Twisted code into the standard library, just standardizing the "protocol" API, which basically boils down to: [...] This sounds great. I'm interested on working on this since i

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 02:28 am, s...@pobox.com wrote: Glyph> ... which is exactly why I have volunteered to explain to someone Glyph> how to separate the core event-loop bits Neil> This sounds great. Anybody interested in working on this at a PyCon Sprint? I won't be attending

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 10:01 am, greg.ew...@canterbury.ac.nz wrote: Hrvoje Niksic wrote: Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. Blarg. Linux is broken, then. This should not happen. You know what else

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 07:30 pm, n...@arctrix.com wrote: Chris McDonough wrote: As far as I can tell, asyncore/asynchat is all "undocumented internals". Any use of asyncore in anger will use internals; there never was any well-understood API to these modules. The implementation requires some intricate and pla

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 4 Mar, 09:36 pm, dan...@stutzbachenterprises.com wrote: Will any or all of you be at PyCon? I'd be willing to put in the extra work to turn your notes into a PEP. I definitely will be. I'll see you there! ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 4 Mar, 08:28 pm, ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 4, 2009, at 2:44 PM, gl...@divmod.com wrote: Maintaining compatibility with the 2.6.x version of asyncore presupposes that *someone* has written some software against that version of asyncore and

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 4 Mar, 09:14 pm, krs...@solarsail.hcs.harvard.edu wrote: I spent about a half hour sometime in the last month talking this through with Itamar, though not in great detail. I'd be interested in sitting down with both of you and trying to establish more precisely how much work is necessary to

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 06:51 pm, exar...@divmod.com wrote: On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum wrote: On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone wrote: So, as a disinterested party in this specific case, I'd say revert to the pre-2.6 behavior. Sorry, but I really do think that we

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 3 Mar, 10:20 pm, gu...@python.org wrote: On Tue, Mar 3, 2009 at 1:17 PM, wrote: At the very least, this might serve as a basis for an abstract API for asyncore: http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.interfaces.IProtocol.html I hope we have learned from asyncor

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 08:46 pm, gu...@python.org wrote: This seems to be the crux of the problem with asyncore, ever since it was added to the stdlib -- there's no real API, so every change potentially breaks something. I wish we could start over with a proper design under a new name. Might I suggest "reactor"..

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

On 07:07 pm, br...@python.org wrote: On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone wrote: But there is another issue with this: the pure Python code will never call the extension code because the globals will be bound to _pypickle and not _pickle. So if you have something like:: # _

Re: [Python-Dev] yield * (Re: Missing operator.call)

On 01:00 am, greg.ew...@canterbury.ac.nz wrote: Guido van Rossum wrote: We already have yield expressions and they mean something else... They don't have a "*" in them, though, and I don't think the existing meaning of yield as an expression would carry over into the "yield *" variant, so the

Re: [Python-Dev] Python-3.0, unicode, and os.environ

structorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) java.io.FileNotFoundException: java.io.FileNotFoundException: ./ÿFDÿFD (No such file or directo

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 06:07 am, [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On Sat, Dec 6, 2008 at 10:53 AM, <[EMAIL PROTECTED]> wrote: I find it interesting to note that the only users in this discussion who actually have these problems in real life all have this attitude. For file managers and simi

Re: [Python-Dev] RELEASED Python 3.0 final

On 08:51 pm, [EMAIL PROTECTED] wrote: On Sat, Dec 6, 2008 at 12:19 PM, <[EMAIL PROTECTED]> wrote: I also don't think 3.0 is perfect, and five years on, there will be a temptation to make more "just this once" incompatible changes. Of course, you've promised these changes won't be made, and *

Re: [Python-Dev] RELEASED Python 3.0 final

On 06:16 pm, [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 10:03 PM, <[EMAIL PROTECTED]> wrote: I do think that in many cases *some* support from the regular maintainers of a library would be needed -- for example if you (in particular) were to express a negative attitude towards porting T

Re: [Python-Dev] RELEASED Python 3.0 final

As far as the original point of this thread, I started off just defending the cautionary text already present in the announcements and on the website. Since I'm not advocating any changes to that (the brief caveat on the "download" page is fine), we'll just have to agree to disagree on the abs

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 02:34 pm, [EMAIL PROTECTED] wrote: On Fri, Dec 05, 2008 at 08:37:45PM -0500, James Y Knight wrote: On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote: You can't display a non-decodable filename to the user, hence the user will have no idea what they're working on. Non-filesystem related apps h

Re: [Python-Dev] RELEASED Python 3.0 final

On 10:12 am, [EMAIL PROTECTED] wrote: When he learned he had to go back and relearn and fix them by hand, his actual words were "if thats the case, I'm gonna be forced to use another language". I hope that isn't a typical example of such a case, but I can partly understand the sentiment. Thi

Re: [Python-Dev] RELEASED Python 3.0 final

On 01:47 am, [EMAIL PROTECTED] wrote: In spite of Python being a programming language, there is a difference between 'casual user of the language' and 'library developer'; 3.0 is certainly a must for all actual library developers, and I'm sure most of them know about 3.0 by now. We're talking ab

Re: [Python-Dev] RELEASED Python 3.0 final

On 5 Dec, 06:10 pm, [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 11:27 PM, <[EMAIL PROTECTED]> wrote: With all due respect, for me, "library support" and "serious use" are synonymous. Glyph, I cannot have a discussion with you if every single post of yours

Re: [Python-Dev] RELEASED Python 3.0 final

On 06:05 am, [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 9:40 PM, <[EMAIL PROTECTED]> wrote: The default case, the case of the user without the wherewithal to understand the nuances of the distinction between 2.x and 3.x, is a user who should use 2.x. Not at all clear. If they're not s

Re: [Python-Dev] RELEASED Python 3.0 final

On 04:16 am, [EMAIL PROTECTED] wrote: I hear some folks are considering advertising 3.0 as experimental or not ready for serious use yet. With all due respect, for me, "library support" and "serious use" are synonymous. When prompted I would say that 2.5 is probably the version that a new Py

Re: [Python-Dev] RELEASED Python 3.0 final

On 4 Dec, 07:12 pm, [EMAIL PROTECTED] wrote: The latter statement worries me. It seems to unnecessarily undermine adoption of 3.0. It essentially says, "don't use this". Is that what we want? I think so. The default case, the case of the user without the wherewithal to understand the nua

Re: [Python-Dev] RELEASED Python 3.0 final

On 02:35 am, [EMAIL PROTECTED] wrote: On Thu, Dec 04, 2008 at 05:29:31PM -0800, Raymond Hettinger wrote: Here's a bright idea. On the 3.0 release page, include a box listing which major third-party apps have been converted. Update it once every couple of weeks. That way, we're not explicitly

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 02:32 am, [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 6:14 PM, James Y Knight <[EMAIL PROTECTED]> wrote: FWIW, I still agree with Martin that that's the most reasonable solution. It died because nobody presented a viable solution, and I maintain no solution is possible. All suggesti

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 02:08 am, [EMAIL PROTECTED] wrote: James Y Knight wrote: On Dec 4, 2008, at 6:39 PM, Martin v. L�wis wrote: I'm in favour of a different, fifth solution: 5) represent all environment variables in Unicode strings, including the ones that currently fail to decode. (then do the same to fil

Re: [Python-Dev] XXX do we need a new policy?

On 02:47 am, [EMAIL PROTECTED] wrote: I disagree. They should be removed when the issue they refer to is removed. No sooner, no later. Simply removing every XXX comment older than a year would not be helpful. The code base is so large that over 2000 XXX doesn't faze me particular. There are over

Re: [Python-Dev] XXX do we need a new policy?

" and "what" happens in the docstring, so we only have comments in areas of code where the "how" or the "who" (i.e. "only JP and Glyph understand this") is difficult to understand. In Twisted, this is almost always some wicked busted operating system

Re: [Python-Dev] Has python-dev collapsed?

On 29 Oct, 09:14 pm, [EMAIL PROTECTED] wrote: Will 3.1 and 2.7 also be parallel releases? (I ask, not having read the 3xxx PEPS at all.) If yes, why? While I can see a case for 2.6/3.0 being in sync -- new features in 2.6 ease the transition to 3.0 -- I'd imagine that 3.1 would be better with

Re: [Python-Dev] is the 'path' argument to an importer's find_module() just a hint?

On 08:44 pm, [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 1:30 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: If the current system is setting __path__ to a string in frozen packages, I'd have to wonder how well any existing __path__ manipulation tools handle frozen packages without special

Re: [Python-Dev] is the 'path' argument to an importer's find_module() just a hint?

On 08:24 pm, [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 12:31 PM, <[EMAIL PROTECTED]> wrote: On 07:24 pm, [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 3:50 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: For what it's worth, Twisted uses the __path__ attribute to facilitate its plu

Re: [Python-Dev] is the 'path' argument to an importer's find_module() just a hint?

On 07:24 pm, [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 3:50 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: Brett Cannon wrote: Good enough for me. Then I am just going to ignore the 'path' argument for frozen modules but use it to short-circuit imports for built-in modules. For what it'

Re: [Python-Dev] [ANN] VPython 0.1

On 23 Oct, 10:42 pm, [EMAIL PROTECTED] wrote: Guido van Rossum wrote: there already is something else called VPython Perhaps it could be called Fython (Python with a Forth-like VM) or Thython (threaded-code Python). I feel like I've missed something important, but, why not just call it "Pyt

Re: [Python-Dev] Documentation idea

On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote: Background -- In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those equivalents are only approximate but they seem to have greatly enhanced the docs. Why not go the other

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

On 11:12 pm, [EMAIL PROTECTED] wrote: - The backport to release26-maint http://svn.python.org/view?rev=66865&view=rev also merged other changes (new unrelated unit tests). IMO unrelated changes should be committed separately: different commit messages help to understand the motivation of each

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 03:54 pm, [EMAIL PROTECTED] wrote: I'm actually sort of liking this idea. A Pathname class, for convenience a subtype of String, but containing the underlying binary representation used by the OS. Even non-unicode pathnames could be represented. On the one hand, I agree with you - excep

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 03:32 am, [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 10:06 PM, [EMAIL PROTECTED] wrote: Can you clarify what proposal you are supporting for Python: Sure. Neither of your descriptions is terribly accurate, but I'll try to explain. 1) Two sets of APIs, one returning unicode strings, an

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 30 Sep, 09:22 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 1:04 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Guido van Rossum wrote: On Mon, Sep 29, 2008 at 11:00 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Martin, I don't understand why you are in favor of storing raw by

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 30 Sep, 09:37 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:42 AM, <[EMAIL PROTECTED]> wrote: There are other ways to glean this knowledge; for example, looking at the 'iocharset' or 'nls' mount options supplied to mount various filesystems. I know we could do a better job, but

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

On 05:56 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 10:59 AM, <[EMAIL PROTECTED]> wrote: On 02:32 pm, [EMAIL PROTECTED] wrote: In the absence of a 2.6 getcwdb, perhaps the fixer could just drop the "benefit of the doubt" case? It could always be added to 2.7, and the parity relea

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 06:16 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:12 AM, <[EMAIL PROTECTED]> wrote: The one thing it doesn't do is expose the decoding rules for the higher- level applications to deal with. I am pretty sure I don't understand how the interaction between filesystem encoding and

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 02:39 pm, [EMAIL PROTECTED] wrote: For example, implementing os.listdir to return the file names as Unicode subclasses with ability to access the underlying bytes (automatically recognized by open and friends) sounds like a good compromise that allows the word processor to both have the cake

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

On 02:32 pm, [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 6:21 AM, <[EMAIL PROTECTED]> wrote: On 12:47 am, [EMAIL PROTECTED] wrote: It sounds like maybe there should be some 2to3 fixers in here somewhere, too? Not necessarily as part of this patch, but somewhere related? I don't know

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

On 12:47 am, [EMAIL PROTECTED] wrote: This is the most sane contribution I've seen so far :). See attached patch: python3_bytes_filename.patch Using the patch, you will get: - open() support bytes - listdir(unicode) -> only unicode, *skip* invalid filenames (as asked by Guido) Forgive me fo

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 11:59 am, [EMAIL PROTECTED] wrote: Sorry, I wasn't clear enough. I'll try to explain further... Let's assume we have a filename like this: 0xc2 0xa9 0x2f 0x7f The first two bytes are the copyright sign encoded in UTF-8, followed by a slash (0x2f, path separator) and a character encoded i

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 10:50 am, [EMAIL PROTECTED] wrote: On Sunday 28 September 2008, Gregory P. Smith wrote: "broken" systems will always exist. Code to deal with them must be possible to write in python 3.0. since any given path (not just fs) can have its own encoding it makes the most sense to me to let the

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On 10:35 pm, [EMAIL PROTECTED] wrote: It is not hard to force an import of warnings to use the pure Python version and totally ignore the C implementation. See test_warnings on how to pull that off. Then you can do your hack of overriding warn_explicit(). Benjamin Peterson's recommendation sou

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On 10:18 pm, [EMAIL PROTECTED] wrote: That's why catch_warning keeps track of the warnings filter too, so you can call warnings.simplefilter("always") within the context manager and the filter state will be restored. Thanks for the pointer - this is interesting. I misunderstood the way the wa

[Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

With the 2.6 final release impending, the Twisted community buildbot is still red, , but there only seems to be one real issue: the warn_explicit change. This seems like it could be a pretty minor bit of maintenance to clear up on our end, if Python provided the appropri

Re: [Python-Dev] Things to Know About Super

On 06:33 pm, [EMAIL PROTECTED] wrote: On Aug 29, 2008, at 11:46 AM, Michele Simionato wrote: On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: I am very well aware of the collection module and the ABC mechanism. However, you are missing that mixins can be implemented in

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 6 Jul, 09:09 pm, [EMAIL PROTECTED] wrote: On Sun, Jul 6, 2008 at 8:46 AM, <[EMAIL PROTECTED]> wrote: It's one thing to tell people that they need to be helping out (and I'm sure you're right) but it's much more useful to get the message out that "we really need people to do X, Y, and Z".

Re: [Python-Dev] Community buildbots and Python release quality metrics

y easily. How shall we arrange it, then? :) Whoever is interested, I've got a recent SSH key on https://launchpad.net/~glyph/+sshkeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-de

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 01:02 am, [EMAIL PROTECTED] wrote: To bring my $0.02 to this discussion: the Pybots 'community buildbots' turned out largely to be a failure. Let's not say it's a failure. Let's instead say that it hasn't yet become a success :-). I still haven't given up, and I hope this thread will spur

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 26 Jun, 09:24 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 1:06 PM, <[EMAIL PROTECTED]> wrote: On 07:44 pm, [EMAIL PROTECTED] wrote: Well, sorry, that's life. We're not going to deal with breakage in 3rd party code on a "drop all other work" basis. For the record, "automatic rev

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 09:17 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 12:35 PM, <[EMAIL PROTECTED]> wrote: Because the relevant community buildbot turned red with that revision of trunk. Keep in mind I'm not talking about every piece of Python code in the universe; just the ones selected for the c

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 07:44 pm, [EMAIL PROTECTED] wrote: At no time will a policy "the community buildbots must be green" be useful: the tests that run on these buildbots are not under our control, so if the tests test things we deem non-public we can't do anything about it. (And we may have a hard time convincin

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 05:14 pm, [EMAIL PROTECTED] wrote: I don't know. JP is already addressing the issues affecting Twisted in another thread (incompatible changes in the private-but-necessary-to- get-any-testing-done API of the warnings module). But I really think that whoever made the change which broke it s

Re: [Python-Dev] Community buildbots and Python release quality metrics

I do tend to ramble on, so here's an executive summary of my response: I want python developers to pay attention to the community buildbots and to treat breakages of existing projects as a serious issue. However, I don't think that maintaining those projects is the core team's job, so all I'

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 04:42 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: an explanation about *why* Django cannot even be imported than a blanket complaint that this is a disgrace. So why is it? and already discussed: http://mail.python.org/pipermail/

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 03:42 pm, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: beta 1 has some trouble running *our* test suite - I'd be fairly surprised if the community buildbots were in significantly better shape. That's another problem, yes :) The community buildbots have been in a broken state for mo

Re: [Python-Dev] Community buildbots and Python release quality metrics

On 03:33 pm, [EMAIL PROTECTED] wrote: Too verbose, Glyph. :-) Mea culpa. "Glyph" might be a less appropriate moniker than "Altogether too many glyphs". It needs to be decided case-by-case. If certain tests are to be ignored on a case-by-case basis, why not rec

[Python-Dev] Community buildbots and Python release quality metrics

Today on planetpython.org, Doug Hellman announced the June issue of Python magazine. The cover story this month is about Pybots, "the fantastic automation system that has been put in place to make sure new releases of Python software are as robust and stable as possible". Last week, there was

Re: [Python-Dev] Py3k DeprecationWarning in stdlib

On 10:05 pm, [EMAIL PROTECTED] wrote: We need to be especially careful with the unit test suite itself - changing the test code to avoid the warning will normally be the right answer, but when the code is actually setting out to test the deprecated feature we need to suppress the warning in the

Re: [Python-Dev] Module renaming and pickle mechanisms

On 10:22 pm, [EMAIL PROTECTED] wrote: When I brought this up earlier, various people assured me that it wasn't a problem in practice. I think we're seeing one situation here where it *is* a problem. Just my two cents here - experience has taught me that it's definitely a problem in practice.

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 3 May, 11:34 pm, [EMAIL PROTECTED] wrote: On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote: Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. What's most interesting (to me) i

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 05:53 pm, [EMAIL PROTECTED] wrote: On May 1, 2008, at 7:54 PM, Barry Warsaw wrote: Interesting. I'm of the opposite opinion. I really don't want Python dictating to me what my home directory should look like (a dot file doesn't count because so many tools conspire to hide it from me).

Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008

On 11:01 am, [EMAIL PROTECTED] wrote: On Friday 02 May 2008, Nick Coghlan wrote: This sums up my opinion pretty well. Hidden by default, but easy to expose (e.g. via a local -> .local symlink) for the more experienced users that want it more easily accessible. But you can't be serious about

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 03:49 am, [EMAIL PROTECTED] wrote: I stand corrected on a few points. You've convinced me that ~/lib/ is wrong. But I still don't like ~/.local/; not in the last place because it's not any more local than any other dot files or directories. The "symmetry" with /usr/local/ is pretty weak, and

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 01:55 am, [EMAIL PROTECTED] wrote: On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote: Hi everybody. I apologize for writing yet another lengthy screed about a simple directory naming issue. I feel strongly about it but I encourate anyone who doesn't to simply skip it. First, s

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

On 11:45 pm, [EMAIL PROTECTED] wrote: I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manag

Re: [Python-Dev] shal we redefine "module" and "package"?

On 10:53 pm, [EMAIL PROTECTED] wrote: zooko wrote: Unfortunately these answers aren't quite right. A "package" is actually a directory containing an __init__.py file, and a distribution is actually what you think of when you say "package" -- a reusable package of Python code that you can,

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

On 09:33 am, [EMAIL PROTECTED] wrote: >I'll chime in here, too. I really want to like >setuptools/easy_install, but I don't. I'll try to be specific in my >reasons, in the hope that they can be addressed. I know some of these >are "known about", but one of my meta-dislikes of setuptools is that >k

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

On 08:34 pm, [EMAIL PROTECTED] wrote: Martin v. L�wis wrote: You seem to be implying that some projects may release separate source distributions. I cannot imagine why somebody would want to do that. That's odd. I can't imagine why anybody would *not* want to do that. Python 2 is going to

Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

On 02:21 pm, [EMAIL PROTECTED] wrote: >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine >>with me. > >This strikes me as a gratuitous API change of the kind Guido was >warning about in his recent post: "Don't change your APIs incompatibly >when porting to Py3k" I agree empha

<    1   2   3   4   5   >