Re: [Python-Dev] Top-posting on this list

On Sat, Oct 10, 2009 at 8:02 PM, Greg Ewing wrote: > That's no reason to squander it, though. Quoting the entire > message every time makes the size of the thread grow as > O(n**2), and makes things harder to read as well. That's > just senseless. Most importantly, insufficient trimming makes man

Re: [Python-Dev] Top-posting on this list

Greg Ewing writes: > That's no reason to squander it, though. Quoting the entire > message every time makes the size of the thread grow as > O(n**2), Agreed, but let's not exaggerate. Threads are finite, so big O is not really relevant. Spam OTOH is boundless, and that's where the bandwidth

Re: [Python-Dev] Top-posting on this list

Stephen J. Turnbull wrote: In the modern environment bandwidth is not really a consideration, That's no reason to squander it, though. Quoting the entire message every time makes the size of the thread grow as O(n**2), and makes things harder to read as well. That's just senseless. The only po

Re: [Python-Dev] PEP 370 and IronPython

Brett Cannon wrote: On Sat, Oct 10, 2009 at 10:31, Michael Foord mailto:fuzzy...@voidspace.org.uk>> wrote: Brett Cannon wrote: On Fri, Oct 9, 2009 at 11:32, Michael Foord mailto:fuzzy...@voidspace.org.uk>

Re: [Python-Dev] PEP 370 and IronPython

On Oct 10, 2009, at 2:17 PM, Brett Cannon wrote: The one unfortunate thing about this proposal is how this is going to mean I have to install a package potentially four times if I want it available to all possible Python interpreters. Then again, the chances of anyone beyond the people on

Re: [Python-Dev] PEP 370 and IronPython

On Sat, Oct 10, 2009 at 10:31, Michael Foord wrote: > Brett Cannon wrote: > >> >> >> On Fri, Oct 9, 2009 at 11:32, Michael Foord >> > fuzzy...@voidspace.org.uk>> wrote: >> >>The *only* change in semantics I'm proposing is for users of >>IronPython 2.6 which is not even at final release ye

Re: [Python-Dev] PEP 370 and IronPython

Michael wrote: > The IronPython team currently have legal issues distributing modified > versions of the standard library (Dino can correct me if I'm wrong > here). It's actually not due to legal issues although we'd have to check w/ the lawyers if we wanted to do it. It's mainly that we don't w

Re: [Python-Dev] Initialization of __builtins__

Vinay Sajip wrote: If __builtins__ is an implementation detail which can't be relied on, should the py3k code be changed to the try: form? Or shall I just remove the checks altogether, since Unicode should always be there in 3.x? Remember that the identifier "unicode" isn't present in py3k. The

Re: [Python-Dev] Initialization of __builtins__

Antoine Pitrou pitrou.net> writes: > Why do you do this? > In py3k, unicode is always enabled but it's called "str" and the name > "unicode" > doesn't exist. > That wasn't done by me but by GvR (according to svn annotate) in r55818, presumably during the stdlib porting to py3k. I just copied t

Re: [Python-Dev] Initialization of __builtins__

Vinay Sajip yahoo.co.uk> writes: > > In the py3k branch, logging has the line > > _unicode = 'unicode' in dir(__builtins__) Why do you do this? In py3k, unicode is always enabled but it's called "str" and the name "unicode" doesn't exist. > to determine the existence of Unicode support. The co

Re: [Python-Dev] Initialization of __builtins__

2009/10/10 Vinay Sajip : > Excuse my ignorance, but how come? Because __builtins__ is a module in __main__ and a dict in other places. You should always check __builtin__; __builtins__ is an implementation detail. -- Regards, Benjamin ___ Python-Dev m

[Python-Dev] Initialization of __builtins__

>I'm not top-posting, but gmane is giving me a hard time :-( In the py3k branch, logging has the line _unicode = 'unicode' in dir(__builtins__) to determine the existence of Unicode support. The code in trunk, being 1.5.2 compatible, used hasattr(types, 'UnicodeType') I wanted to eliminate the

Re: [Python-Dev] PEP 370 and IronPython

Brett Cannon wrote: On Fri, Oct 9, 2009 at 11:32, Michael Foord > wrote: The *only* change in semantics I'm proposing is for users of IronPython 2.6 which is not even at final release yet. CPython users would be unaffected. Then why can't IronPy

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Michael Foord wrote: > Why not just sys.implementation as a string? Everything else can > trivially be deduced from that anyway. What is the use-case for the > extra information? I think Christian's set of required attributes is much too large (I would only have "name" as a required field), but I

Re: [Python-Dev] transitioning from % to {} formatting

Nick Coghlan wrote: Benjamin Peterson wrote: 2009/10/8 Eric Smith : Christian Tanzer wrote: IMHO, either the translation is done once and gives identical output or it isn't worth doing at all. I disagree. I doubt even 0.001% of all format strings involve octal formatting. Is it really worth n

Re: [Python-Dev] transitioning from % to {} formatting

Glenn Linderman wrote: > If you want to replace a C program that produces parsed output in a > given format, and that given format includes leading-0-octal numbers, > then it would be good to have the capability in Python .format, even > though Python itself uses 0o prefix. > > Similar arguments m

Re: [Python-Dev] transitioning from % to {} formatting

Benjamin Peterson wrote: > 2009/10/8 Eric Smith : >> Christian Tanzer wrote: >>> IMHO, either the translation is done once and gives identical output or >>> it isn't worth doing at all. >> I disagree. I doubt even 0.001% of all format strings involve octal >> formatting. Is it really worth not prov

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Christian Heimes wrote: Fellow Python developers! In the light of our recent discussion about implementation specific information and user site directory I like to start a new PEP. Much to my regret I wasn't able to contribute to Python core development over the past months. I hope I can find so

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Martin v. Löwis wrote: > Doing some bike-shedding: I'd like to not use "cpython" as the name of > the python.org implementation. This term, I believe, was coined around > JPython, somehow making the implementation language the primary means > of distinction. However, there may be alternative implem

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

M.-A. Lemburg wrote: > Benjamin Peterson wrote: >> I forgot to ask before: Does this deprecate platform.python_implementation()? > > No, platform.py is meant to be portable across multiple Python > versions and as such not really suitable for such deprecations. > > It'll also take a long while be

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

2009/10/10 Willem Broekema : > On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes wrote: >> I'm proposing two new attributes in the sys module: sys.implementation >> and sys.userdirsuffix. > > This seems like a good idea. > > I'm not sure this idea will easily be accepted, but I'd like to see > the

Re: [Python-Dev] PEP about sys.implementation and impleme ntation specific user site directory

Willem Broekema gmail.com> writes: > > a) implementation details of the C implementation (subversion, _*, > dllhandle, dont_write_bytecode, settscdump, ..) in one module, > > b) portable functionality (interpreter name and version etc, > builtin_module_names, copyright, excepthook, settrace, ..)

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

Benjamin Peterson wrote: > I forgot to ask before: Does this deprecate platform.python_implementation()? No, platform.py is meant to be portable across multiple Python versions and as such not really suitable for such deprecations. It'll also take a long while before all Python implementations ex

Re: [Python-Dev] eggs now mandatory for pypi?

"Martin v. Löwis" wrote: >> I know that the issue tracker for PyPI is (still) on SF, but >> development appear to happen elsewhere and I can't find any >> contact information on the PyPI web pages. > > PyPI discussion takes place mostly on catalog-sig. Ok, then I'll sign up there. Thanks, -- Ma

[Python-Dev] Top-posting on this list

Brett Cannon writes: > On Fri, Oct 9, 2009 at 11:32, Michael Foord wrote: > > Sorry for top-posting, mobile device. Michael, I for one *very much* appreciate your courtesy. > Aahz was the most adamant hater of top-posting and he isn't subscribed to > python-dev anymore, so whatever. Please

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes wrote: > I'm proposing two new attributes in the sys module: sys.implementation > and sys.userdirsuffix. This seems like a good idea. I'm not sure this idea will easily be accepted, but I'd like to see the sys module eventually split up in two pa