Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

quiring newcomers to learn our weird technology religion before they can contribute creates a real barrier to entry, which in turn makes our community more insular and homogenous. Some days you get the Git, and some days the Github gets you. The sooner we, as a community and a culture, can a

Re: [Python-Dev] Yearly PyPI breakage

;t even need to build C code. cdecimal users may wish to retrieve it via this mechanism until there's a secure way to get the proper upstream distribution. If anyone wants package-index access to this name to upload Windows or manylinux wheels just let me know; however, as this is just a pr

Re: [Python-Dev] Yearly PyPI breakage

On May 3, 2016, at 9:15 PM, Stefan Krah wrote: > >> [cut overlong post] > > Glyph, > > nice sneaky way to try to divert from the original issue. The original issue, as I understood it, at the start of the thread was "which hoops I have to jump through this year in o

[Python-Dev] Re: What is a public API?

d an extremely small project called "publication" (https://pypi.org/project/publication/ <https://pypi.org/project/publication/>, https://github.com/glyph/publication <https://github.com/glyph/publication>) which attempts to harmonize the lofty ideal of "only the names e

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Feb 25, 2013, at 12:32 PM, Barry Warsaw wrote: >> Dumb question, but are flufl.enums ordered? That's also an important use >> case. > > Kind of. Ordered comparisons are explicitly not supported, but iteration over > the Enum is guaranteed to be returned in int-value order. Sorry to jump i

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Feb 26, 2013, at 5:25 AM, Eli Bendersky wrote: > Glyph, thanks for the input. I mentioned Twisted because in its code I found > a number of places with simple string enumerations used to represent state. I > was not aware of twisted.python.constants, but it doesn't ap

Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

testing SIG someone from Twisted ought to be a member of, to represent Trial, and to get consensus on these points going forward? -glyph ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] About issue 6560

ease file a bug (at <http://twistedmatrix.com/>). -glyph ___ 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] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

On Mar 25, 2013, at 1:40 PM, Benjamin Peterson wrote: > ... Assuming PEP 343 becomes policy ... Are you sure you got this PEP number right? The 'with' statement? -glyph___ Python-Dev mailing list Python-De

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] 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] 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] 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 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 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 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: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 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 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 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 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: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] 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] "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

[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] 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] 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] 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?

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] 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] 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 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] 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 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 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] 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] 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 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 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] 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

[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] 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

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 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 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 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] draft pep: backwards compatibility

On 02:17 am, benja...@python.org wrote: Backwards compatibility seems to be an issue that arises a lot here. I think we all have an idea of it is, but we need some hard place to point to. So here's my attempt: PEP: 387 Title: Backwards Compatibility Policy Thanks for getting started on this

Re: [Python-Dev] draft pep: backwards compatibility

On 09:21 am, solip...@pitrou.net wrote: divmod.com> writes: In order for any changes to be possible, there needs to be a clearly labeled mine-field: don't touch or depend on these things in your Python application or it *will* break every time Python is released. I think the "frozen area"

Re: [Python-Dev] draft pep: backwards compatibility

On 11:11 am, solip...@pitrou.net wrote: divmod.com> writes: This is a false dichotomy; for core developers, the list needs to be exhaustive. Everything that can change needs to be described as either compatible or incompatible. How do you enumerate "everything that can change"? It does n

Re: [Python-Dev] draft pep: backwards compatibility

On 11:13 am, fuzzy...@voidspace.org.uk wrote: Just to note that Twisted (along with Bazaar) are one of the few 'good citizens' in the Python community running their tests on Python trunk. Both projects have caught incompatibilities *before* release of new versions which is greatly preferable to

Re: [Python-Dev] draft pep: backwards compatibility

On 02:09 pm, benja...@python.org wrote: 2009/6/19 : On 02:17 am, benja...@python.org wrote: I've taken a stab at this myself in the past while defining a policy for Twisted Yes, that's helpful. Thanks. Glad you found it useful. The questions that follow might seem satirical or parodi

Re: [Python-Dev] draft pep: backwards compatibility

On 07:06 pm, pyt...@rcn.com wrote: Not sure why we need yet another pep on the subject. Just update PEP 5 if needed. Hmm. This is a good point; it might make sense to have a more specific PEP for library compatibility as opposed to language compatibility though, since language compatibility

Re: [Python-Dev] draft pep: backwards compatibility

On 19 Jun, 09:08 pm, benja...@python.org wrote: 2009/6/19 : On 02:09 pm, benja...@python.org wrote: 2009/6/19 �: �What about side-effects, or exceptional conditions? �What about interactions with subclasses?  (Changing a class in a library from old-style to new-style has serious re

Re: [Python-Dev] PEP 376 - Open questions

On 02:55 am, e...@trueblade.com wrote: I really don't get this use case of multiple installers trying to install the same package. There's just no way that running "yum install twisted" and "apt-get install twisted" and "pip install twisted" are going to coexist with each other. The best they c

Re: [Python-Dev] PEP 376 - Open questions

On 03:28 am, e...@trueblade.com wrote: Eventually, I'd like PEP 376 to support system packagers too. So for example, if you did "apt-get install python-pyqt4", then running "pip install python-pyqt4" should return without installing anything .. as RECORD will be part of the .deb previously inst

[Python-Dev] Community buildbots (was Re: User's complaints)

On Wed, 12 Jul 2006 10:30:17 +1000, Michael Ellerman <[EMAIL PROTECTED]> wrote: >Well here's one I stumbled across the other day. I don't know if it's >legit, but it's still bad PR: > >http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html Having been exhorted (or maybe I mean "excoriate

Re: [Python-Dev] Community buildbots

On Thu, 13 Jul 2006 19:19:08 +0100, Michael Hudson <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] writes: >> For example, did anyone here know that the new-style exceptions stuff in 2.5 >> caused hundreds of unit-test failures in Twisted? I am glad the change was >> made, and one of our users did

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

On Thu, 13 Jul 2006 11:29:16 -0700, Aahz <[EMAIL PROTECTED]> wrote: >There's been some recent discussion in the PSF wondering where it would >make sense to throw some money to remove grit in the wheels; do you think >this is a case where that would help? Most likely yes. It's not a huge undert

Re: [Python-Dev] Community buildbots

On Thu, 13 Jul 2006 23:27:56 -0500, [EMAIL PROTECTED] wrote: >The buildbot idea sounds excellent. Thanks. If someone can set this up, it pretty much addresses my concerns. >If you're concerned about noticing when a new release train is pulling out >of the station I think it would be sufficient

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

perly test to see if there *are* problems. Keep in mind though: just because the problems are small or easy to fix doesn't mean they're not severe. One tiny bug can prevent a program from even starting up. >Admittedly, I'm not as sophisticated a user as Fredrik or Glyph, but I >su

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

On Thu, 13 Jul 2006 23:39:06 -0700, Neal Norwitz <[EMAIL PROTECTED]> wrote: >On 7/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >> a longer beta period gives *external* developers more time to catch up, >> and results in less work for the end users. >This is the part I don't get. For the exter

Re: [Python-Dev] Community buildbots

On Fri, 14 Jul 2006 23:38:52 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >Christopher Armstrong wrote: >> python -U is a failure for obvious reasons and a >> __future__ import is clearly better. > >I disagree. I am surprised that you do, since I thought that Chris's conclusion was pr

Re: [Python-Dev] Community buildbots

On Sat, 15 Jul 2006 00:13:35 -0400, Terry Reedy <[EMAIL PROTECTED]> wrote: >Is the following something like what you are suggesting? Something like it, but... >A Python Application Testing (PAT) machine is set up with buildbot and any >needed custom scripts. Sometime after that and after 2.5

Re: [Python-Dev] Community buildbots

On Sat, 15 Jul 2006 14:35:08 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] wrote: >>A __future__ import would allow these behaviors to be upgraded module-by- >>module. > >No it wouldn't. Yes it would! :) >__future__ works solely on the semantics of different pieces of syntax,

Re: [Python-Dev] Community buildbots

On Sat, 15 Jul 2006 10:43:22 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >People can use [-U] to improve the Unicode support in the Python standard >library. When they find that something doesn't work, they can study the >problem, and ponder possible solutions. Then, they can contribu

Re: [Python-Dev] Dynamic module namspaces

On Mon, 17 Jul 2006 10:29:22 -0300, Johan Dahlin <[EMAIL PROTECTED]> wrote: >I consider __getattribute__ a hack, being able to override __dict__ is less >hackish, IMHO. Why do you feel one is more "hackish" than the other? In my experience the opposite is true: certain C APIs expect __dict__ to

Re: [Python-Dev] Problem with super() usage

On Tue, 18 Jul 2006 09:24:57 -0400, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >On Tue, 18 Jul 2006 09:10:11 -0400, Scott Dial <[EMAIL PROTECTED]> wrote: >>Greg Ewing wrote: >>> Guido van Rossum wrote: In the world where cooperative multiple inheritance originated (C++), this would

Re: [Python-Dev] Undocumented PEP 302 protocol change by need-for-speed sprint

On Thu, 20 Jul 2006 14:57:07 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >While investigating the need to apply http://python.org/sf/1525766 I found >that there was a modification to pkgutil during the need-for-speed sprint >that affects the PEP 302 protocol in a backwards incompatible way.

Re: [Python-Dev] uuid tests failing on Windows

On Thu, 17 Aug 2006 22:06:24 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >Georg Brandl schrieb: >>> Can somebody please fix that? If not, should we remove the uuid module >>> as being immature? >> >> Patch #1541863 supposedly solves this. > >Ah, good. I think it should go in. Uh, I ma

Re: [Python-Dev] uuid tests failing on Windows

On Thu, 17 Aug 2006 23:58:27 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >You misunderstand indeed: the chunk reads (...) >it currently calls uuid1, and will call uuid4 when patched. >test_uuid4 should have never failed, except that it uses uuid1 >as the uniqueness test. Whooops. I

Re: [Python-Dev] Suggestion for a new built-in - flatten

On Fri, 22 Sep 2006 18:43:42 +0100, Michael Foord <[EMAIL PROTECTED]> wrote: >I have a suggestion for a new Python built in function: 'flatten'. This seems superficially like a good idea, but I think adding it to Python anywhere would do a lot more harm than good. I can see that consensus is a

Re: [Python-Dev] Suggestion for a new built-in - flatten

On Fri, 22 Sep 2006 20:55:18 +0100, Michael Foord <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] wrote: >>On Fri, 22 Sep 2006 18:43:42 +0100, Michael Foord >><[EMAIL PROTECTED]> wrote: >>This wouldn't be a problem except that everyone has a different idea of >>those requirements:). You didn't r

Re: [Python-Dev] PEP 355 status

On Fri, 29 Sep 2006 12:38:22 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote: >I would recommend not using it. IMO it's an amalgam of unrelated >functionality (much like the Java equivalent BTW) and the existing os >and os.path modules work just fine. Those who disagree with me haven't >done a v

Re: [Python-Dev] PEP 355 status

On Sun, 01 Oct 2006 13:56:53 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: >Things the PEP 355 path object lumps together: > - string manipulation operations > - abstract path manipulation operations (work for non-existent filesystems) > - read-only traversal of a concrete filesystem (dir

Re: [Python-Dev] Path object design

On 03:14 am, [EMAIL PROTECTED] wrote:>One thing is sure -- we urgently need something better than os.path.>It functions well but it makes hard-to-read and unpythonic code.I'm not so sure.  The need is not any more "urgent" today than it was 5 years ago, when os.path was equally "unpythonic" and unr

Re: [Python-Dev] Path object design

On 10:06 am, [EMAIL PROTECTED] wrote:>What a successor to os.path needs is not security, it's a better (more pythonic,>if you like) interface to the old functionality.Why?I assert that it needs a better[1] interface because the current interface can lead to a variety of bugs through idiomatic, appa

Re: [Python-Dev] Path object design

On 06:14 pm, [EMAIL PROTECTED] wrote:>[EMAIL PROTECTED] wrote:>>> I assert that it needs a better[1] interface because the current>> interface can lead to a variety of bugs through idiomatic, apparently>> correct usage.  All the more because many of those bugs are related to>> critical errors such

Re: [Python-Dev] Path object design

On 08:14 pm, [EMAIL PROTECTED] wrote:>Argh, it's difficult to respond to one topic that's now spiraling into>two conversations on two lists.>[EMAIL PROTECTED] wrote:>(...) people have had to spend five years putting hard-to-read>os.path functions in the code, or reinventing the wheel with their own

Re: [Python-Dev] Path object design

On 01:46 am, [EMAIL PROTECTED] wrote:>On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:>This is ironic coming from one of Python's celebrity geniuses.  "We>made this class but we don't know how it works."  Actually, it's>downright alarming coming from someone who knows Twisted inside and>out

Re: [Python-Dev] Path object design

On 01:04 am, [EMAIL PROTECTED] wrote:>[EMAIL PROTECTED] wrote:>If you're serious about writing platform-agnostic>pathname code, you don't put slashes in the arguments>at all. Instead you do>>   os.path.join("hello", "slash", "world")>>Many of the other things you mention are also a>result of not tr

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

On 11:45 pm, [EMAIL PROTECTED] wrote: >I keep thinking I'd like to treat the OS as just another application, >so that there's nothing special about it and the same infrastructure >could be used for other applications with lots of entry level scripts. I agree. The motivation here is that the "OS"

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

On 09:34 am, [EMAIL PROTECTED] wrote: >There's another standard place that is searched on MacOS: a per-user >package directory ~/Library/Python/2.5/site-packages (the name "site- >packages" is a misnomer, really). Standardising something here is >less important than for vendor-packages (as the eff

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

On 29 Nov, 11:49 pm, [EMAIL PROTECTED] wrote: >On Nov 29, 2006, at 5:18 AM, [EMAIL PROTECTED] wrote: >> I'd suggest using "~/.local/lib/pythonX.X/site-packages" for the >> "official" UNIX installation location, ... >+1 from me also for the concept. I'm not sure I like ~/.local though >- -- it s

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

On 12:34 am, [EMAIL PROTECTED] wrote: >The whole concept of "hidden" files seems ill- >considered to me, anyway. It's too easy to forget >that they're there. Putting infrequently-referenced >stuff in a non-hidden location such as ~/local >seems just as good and less magical to me. Something like

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

On 04:11 am, [EMAIL PROTECTED] wrote: >On Wednesday 29 November 2006 22:20, [EMAIL PROTECTED] wrote: > > GNOME et. al. aren't promoting the concept too hard. It's just the first > > convention I came across. (Pardon the lack of references here, but it's > > very hard to google for "~/.local" - I

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

On 04:36 am, [EMAIL PROTECTED] wrote: >easy_install uses the standard distutils configuration system, which means >that you can do e.g. Hmm. I thought I knew quite a lot about distutils, but this particular nugget had evaded me. Thanks! I see that it's mentioned in the documentation, but I

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

On 05:37 pm, [EMAIL PROTECTED] wrote: >Perhaps "pyinstall"? Keep in mind that Python packages will still generally be *system*-installed with other tools, like dpkg (or apt) and rpm, on systems which have them. The name of the packaging system we're talking about is called either "eggs" or "se

Re: [Python-Dev] [Python-checkins] MSI being downloaded 10x more than all other files?!

On 11:17 pm, [EMAIL PROTECTED] wrote: >On 12/11/06, Jim Jewett <[EMAIL PROTECTED]> wrote: >> On 12/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> > /ftp/python/2.5/python-2.5.msi is by far the top download -- 271,971 >> > hits, more than 5x the next one, /ftp/python/2.5/Python-2.5.tgz >> > (4

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 07:42 pm, [EMAIL PROTECTED] wrote: >On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> >><"Anthony Baxter"> >> > Comments? What else should get warnings? >> >>It is my strong preference that we not go down this path. >>Instead, the 2.6 vs 3.0 difference analysis should go in an >>extern

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 10 Jan, 11:10 pm, [EMAIL PROTECTED] wrote: >On 10/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>I've been assuming for some time that the only hope for Py3k compatibility >>within Twisted would be using PyPy as a translation layer. >Does this ring as many warning bells for me as it does

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 11 Jan, 08:22 pm, [EMAIL PROTECTED] wrote: >On 1/11/07, James Y Knight <[EMAIL PROTECTED]> wrote: >> If the goal is really to have Py 3.0 be released later this year, >There will certainly be demand for an asynchronous server in 3.0, To flip the question around: there might be a demand for Twi

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 01:12 am, [EMAIL PROTECTED] wrote: >On Friday 12 January 2007 06:09, James Y Knight wrote: >> On Jan 10, 2007, at 6:46 PM, Benji York wrote: >> > Paul Moore wrote: >> >> How many other projects/packages anticipate *not* migrating to >> >> Py3K, I wonder? >> > >> > I certainly can't speak for the

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 07:56 am, [EMAIL PROTECTED] wrote: >Additionally, without a 2.x<->3.x upgrade path 3.x is essentially a >new language, having to build a new userbase from scratch. Worse >yet, 2.x will suffer as people have the perception "Python 2? >That's a dead/abandoned language" It's worse than that. Thi

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 10:12 am, [EMAIL PROTECTED] wrote: >For practical reasons (we have enough work to be getting on with) PyPy >is more-or-less ignoring Python 2.5 at the moment. After funding and >so on, when there's less pressure, maybe it will seem worth it. Not >soon though. I think I know what you mean fro

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 11:22 am, [EMAIL PROTECTED] wrote: >> FWIW, I also agree with James that Python 3 shouldn't even be >> released until the 2.x series has reached parity with its feature >> set. However, if there's continuity in the version numbers >> instead of the release dates, I can at least explain to Twis

Re: [Python-Dev] The bytes type

On 06:49 pm, [EMAIL PROTECTED] wrote: >I think we should draw a line in the sand and resolve not to garbage-up Py2.6. >The whole Py3.0 project is about eliminating cruft and being free of the >bonds of backwards compatibility. Adding non-essential cruft to Py2.6 >goes against that philosophy. Em

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 09:04 pm, [EMAIL PROTECTED] wrote: >I'm wondering if we might be going the wrong way about warning about >compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0 >alpha had a 2.x compatibility mode command-line flag, which is removed late >in the beta cycle. Please, no. I don

Re: [Python-Dev] file(file)

On 12:37 am, [EMAIL PROTECTED] wrote: >For security reasons I might be asking for file's constructor to be >removed from the type for Python source code at some point (it can be >relocated to an extension module if desired). By forcing people to go >through open() to create a file object you can

Re: [Python-Dev] file(file)

On 02:42 am, [EMAIL PROTECTED] wrote: >Wrapper around open() that does proper checking of its arguments. I >will be discussing my security stuff at PyCon if you are attending and >are interested. I am both, so I guess I'll see you there :). ___ Pyth

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On 08:19 am, [EMAIL PROTECTED] wrote: >Georg Brandl schrieb: >>> If Python 3.0 was simply a release which removed deprecated features, >>> there would clearly be no issue. I would update my code in advance of >>> the 3.0 release to not use any of those features being removed, and >>> I'm all set. B

  1   2   3   4   5   >