Re: [Python-Dev] Binary Operator for New-Style String Formatting

Jerry Chen wrote: Hello all, For better or for worse, I have created a patch against the py3k trunk which introduces a binary operator '@' as an alternative syntax for the new string formatting system introduced by PEP 3101 ("Advanced String Formatting"). [1] For common cases, this syntax shoul

Re: [Python-Dev] run time error anlysis of python source code

omega_force2...@yahoo.com wrote: It appears that one possibility of investigation into the development of a safety-critical variant of the python language would be to conduct run time error analysis of the source code that is responsible for producing the python language. Therefore, I will no

Re: [Python-Dev] xmlrpc improvements

Fredrik Lundh wrote: On Sat, Jun 20, 2009 at 6:57 PM, "Martin v. Löwis" wrote: Fredrik Lundh wrote: I think you really need to get Fredrik Lundh to comment on it. If he can't predict when he'll be able to review the changes, maybe he can accept releasing control of xmlrpclib. Pointer to the pa

Re: [Python-Dev] Adding syntax for units of measure

Tobias C. Rittweiler wrote: Has anyone added special syntax to allow writing numeric literals with physical units? So you can write 12m + 34cm, and would get 12.34m. Python-dev is for concrete discussion of development of the next versions. Questions and speculative discussion should generall

Re: [Python-Dev] ndPython: I NEED TO TALK WITH ONE OF THE PYTHON CORE DEVELOPERS

SUBJECT LINES IN ALL CAPS CREATE NEGATIVE IMPRESSION Filippo Battaglia wrote: [snip questions I cannot answer] Question about existing, older Python versions should be directed to python-list, at least for a first try. Stackless Python is not produced by PSF core developers. It has third-part

Re: [Python-Dev] ndPython: I NEED TO TALK WITH ONE OF THE PYTHON CORE DEVELOPERS

Kristján Valur Jónsson wrote: The OP was redirected here from the stackless list since his questions were not stackless specific. Ok. He should have said so. Third party directions are not always right. As it turns out, he did post to python-list but ignored the rather strong hint about not s

Re: [Python-Dev] ndPython: I NEED TO TALK WITH ONE OF THE PYTHON CORE

Filippo Battaglia wrote: Thanks for your answers. Sorry for the title in upper case. I didn't want to create troubles. :) I've an important question for you: is it possible that a large python module, created using SWIG and with a hundred of routines, makes slower the execution (i.e. the job of

Re: [Python-Dev] Flow of control - a new way - Idea

vin vin wrote: Look up 'trampoline', but ask any further questions on python-list. ___ 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/arch

Re: [Python-Dev] PEP 376

Scott David Daniels wrote: Antoine Pitrou wrote: Guido van Rossum python.org> writes: I noted an inconsistency: first you say that the RECORD file uses the excel dialect, but at the end of the same section you say it uses the default csv settings. Sounds like you need to delete one or the othe

Re: [Python-Dev] I am back

Brett Cannon wrote: On Thu, Jul 2, 2009 at 04:39, Nick Coghlan > wrote: Aahz wrote: > On Wed, Jul 01, 2009, Brett Cannon wrote: >> Anything happen while I was gone that I should be aware of that is not >> covered in a PEP? > > Yes.

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman wrote: It needs to be decided where the hg repositories will live. I'd like to propose to keep the hgwebdir instance at hg.python.org. This is an accepted standard for many organizations, and an easy parallel to svn.python.org. The 2.7 (trunk) repo might live at http://hg.python.

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

MRAB wrote: Terry Reedy wrote: Dirkjan Ochtman wrote: It needs to be decided where the hg repositories will live. I'd like to propose to keep the hgwebdir instance at hg.python.org. This is an accepted standard for many organizations, and an easy parallel to svn.python.org. The 2.7 (

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Brett Cannon wrote: I would very much like the 'k' dropped from the py3 name. It was a funny joke when py3 was vaporware, now it is excess baggage which only puzzles non-insiders and newcomers. Is it really that confusing? I have never heard of anyone asking "what is py3k?" Do

[Python-Dev] Search error on tracker?

Before posting http://bugs.python.org/issue6453 I searched the tracker for 'bool TypeError' to avoid making a duplicate report. A few irrelevant hits were return but not the important one http://bugs.python.org/issue6428 which was the one I needed to find. Going back and searching titles for 'T

Re: [Python-Dev] Search error on tracker?

Martin v. Löwis wrote: Terry Reedy wrote: Before posting http://bugs.python.org/issue6453 I searched the tracker for 'bool TypeError' to avoid making a duplicate report. A few irrelevant hits were return but not the important one http://bugs.python.org/issue6428 which was the one I

Re: [Python-Dev] PEP 376 - from PyPM's point of view

Tarek Ziadé wrote: In any case I don't see any use case to have a "site-packages" remaining in Python itself. I have and am using it. Where else would you have me put library packages meant to be accessible by any Python program? Terry Jan Reedy ___

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

Lisandro Dalcin wrote: On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone wrote: True, CPython has C infrastructure. What about the other Python runtimes, though? Perhaps these other Python runtimes could implement the functionality of PC/_subprocess.c and use ctypes for that ? Is it se

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

Lisandro Dalcin wrote: On Thu, Jul 23, 2009 at 5:42 PM, Terry Reedy wrote: Lisandro Dalcin wrote: On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone wrote: True, CPython has C infrastructure. What about the other Python runtimes, though? Perhaps these other Python runtimes could

Re: [Python-Dev] Update to Python Documentation Website Request

David Lyon wrote: The Python Package Manager can be written to work in console mode. I think this would be best. Haha - I'm glad somebody took this seriously... It was a sort of a joke comment but it's a serious possibility. I took it seriously too ;-). It seems to me that you project can

Re: [Python-Dev] Update to Python Documentation Website Request

Nick Coghlan wrote: David Lyon wrote: Your whole email whilst perphaps technically correct is terribly difficult for a software engineering person to follow. It made perfect sense to me. Like David, I found it a bit disjointed too. The words "eggs" brings with it a whole lot more baggage t

Re: [Python-Dev] standard library mimetypes module pathologically broken?

Jacob Rus wrote: Okay. Well I'd still like to hear a bit about what people really need before trying to make a new API. Try asking some specific question on python-list. "How to you use the stdlib mimetypes module?" ___ Python-Dev mailing list Pyt

Re: [Python-Dev] Tkinter has many files

cool-RR wrote: Hello python-dev! I'm a Python programmer, but this is the first time I'm posting on python-dev, and I am not familiar at all with how the Python implementation works -- so this post may be way off. I've recently released a Python application, PythonTurtle

Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?

Greg Ewing wrote: Benjamin Peterson wrote: It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. Good point. Removing the check sounds like the right thing to do, then. Both classmethod & staticmethod are documented as having a

Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?

P.J. Eby wrote: At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote: Greg Ewing wrote: Benjamin Peterson wrote: It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. Good point. Removing the check sounds like the ri

Re: [Python-Dev] Mercurial migration: help needed

Martin v. Löwis wrote: I'm starting to wonder what the problem really is that makes it so Python-specific. If I understood correctly, it's about a couple of files which must be stored using non-Unix line endings, right? (in the PC and PCbuild directories?) No. It's about files that must, when c

Re: [Python-Dev] PEP 3144 review.

Peter Moody wrote: On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire wrote: Downloading and using are not the same thing. Correct, but there is a strong positive correlation between the two. If you have a better method for determining what you would consider an appropriate level of usage, I'm

Re: [Python-Dev] PEP 3144 review.

Peter Moody wrote: On Wed, Sep 16, 2009 at 1:35 PM, Antoine Pitrou wrote: Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit : Folks, Guido, I believe PEP 3144 is ready for your review. When you get a chance, can you take a look/make a pronouncement? Besides what has already been said

Re: [Python-Dev] PEP 3144 review.

This is my first post in this thread. I do not currently expect to directly use ipaddr, but I am interested in Python having good modules and a friendly development environment. It strikes me that a module that meets the desiderata of broad community support is going to have the 'baggage' of l

Re: [Python-Dev] PEP 3144 review.

Mark Dickinson wrote: On Wed, Sep 30, 2009 at 1:44 AM, Nick Coghlan wrote: Please could someone who understands the uses of IPNetwork better than I do explain why the following wouldn't be a significant problem, if __eq__ and __hash__ were modified to disregard the .ip attribute as suggested:

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

James Y Knight wrote: > allow users to use newstyle string substitution with every API. However it is done, I think someone (like new Python programmers) should be able to program in Python3, and use everything in the stdlib, without ever learning % formatting -- and that I should be able to fo

Re: [Python-Dev] Announcing PEP 3136

Yuvgoog Greenle wrote: I like how python has a minimalistic and powerful syntax (-1 for the break ___ PEP). Also, I really dislike the for/else ambiguity "butterflies". Properly understood, no ambiguity. while c: x() is equivalent to hypothetical label z: if c: x() goto: z So while

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

Antoine Pitrou wrote: Vinay Sajip yahoo.co.uk> writes: Does it seems too onerous to expect people to pass an additional "use_format" keyword argument with every logging call to indicate how to interpret the message format string? Or does the PercentMessage/BraceMessage type approach have any mi

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

Steven Bethard wrote: On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy wrote: As someone who likes .format() and who already uses such bound methods to print, such as in emsg = "...".format ... if c: print(emsg(arg, barg)) I find this **MUCH** preferable to the ugly and seemingly u

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

Benjamin Peterson wrote: 2009/10/2 Raymond Hettinger : [Terry Reedy] I would agree, for instance, that an auto-translation tool is needed. We should get one written. ISTM, every %-formatting string is directly translatable to an equivalent {}-formatting string. Yes, but not all are

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

Steven Bethard wrote: I thought it might be useful for those who don't have time to read a million posts to have a summary of what's happened in the formatting discussion. definitely The basic problem is that many APIs in the standard library and elsewhere support only %-formatting and not {

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

Carl Trachte wrote: I've skimmed over the PEP, and the new {}-syntax seems to have some nice features. But I've not seen it used anywhere yet. I am using it with 3.1 in an unreleased book I am still writing, and will in any code I publish. Rami Chowdhury posted this to a mailing list; I'

Re: [Python-Dev] Python byte-compiled and optimized code

Fred Drake wrote: On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar wrote: 1) Is the byte-compiled .pyc file and optimized .pyo file platform-independent?(including python versions 3.x) Yes. To be clear, CPython's .pyc is platform independent for a particular x.y version, and should, I beli

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

John Arbash Meinel wrote: So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x faster than (iter(s).next()). I was pretty surprised that it was 30% faster than "for x in s: pass". I assume it has something to do with a potential "else:" statement? for x in s: pass iterates throu

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

Steven D'Aprano wrote: On Sat, 24 Oct 2009 08:12:26 pm Martin (gzlist) wrote: There's a different proposed meaning for `set.get` that's been discussed on python-dev before: For that case, I think the OP was mistaken mistak

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

Guido van Rossum wrote: On Sat, Oct 24, 2009 at 10:34 AM, Alexander Belopolsky wrote: To me, however, a set seems to be a container that is a specialization of a dict with values and keys being the same. That's absurd; the mapping provides nothing useful. Given Alexander's premise, I agree

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

Alexander Belopolsky wrote: On Fri, Oct 23, 2009 at 6:46 PM, Steven D'Aprano wrote: On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote: .. fwiw, I think the use case for this is sufficiently rare that it does not need a separate method just for this purpose. And yet it keeps comi

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

Alex Martelli wrote: Next(s) would seem good... That does not work. It has to be next(iter(s)), and that has been tried and eliminated because it is significantly slower. Interesting. It depends a bit on the speed of tuple unpacking, but presumably that is quite fast. On my system it is pre

Re: [Python-Dev] Reworking the GIL

Antoine Pitrou wrote: Hello there, The last couple of days I've been working on an experimental rewrite of the GIL. Since the work has been turning out rather successful (or, at least, not totally useless and crashing!) I thought I'd announce it here. I am curious as to whether the entire mech

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

Alexander Belopolsky wrote: Here is an alternative idea on how storing interned objects in a set can be supported. Currently set.add method returns None and had no effect when set already has an object equal to the one being added. I propose to consider changing that behavior to make set.add r

Re: [Python-Dev] One obvious way to do interning [Was: Retrieve an arbitrary element from a set without removing it]

Alexander Belopolsky wrote: Changing the subject to reflect branched discussion and forwarding to python-ideas where it probably belongs. On Mon, Oct 26, 2009 at 12:02 PM, Terry Reedy wrote: Alexander Belopolsky wrote: Here is an alternative idea on how storing interned objects in a set can

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

Raymond Hettinger wrote: A dict.get() can be meaningfully used in a loop (because the key can vary). A set.get() returns the same value over and over again (because there is no key). There are two ideas of set.get floating about: 1) get an arbitrary object 2) get the object in the set with th

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

sstein...@gmail.com wrote: On Oct 27, 2009, at 2:50 PM, Terry Reedy wrote more and more and more and more and more and more and more and more and more: Actually, I wrote 7 succinct lines that summarized and made a proposal. In general, I snip when quoting and write concisely as possible

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

Guido van Rossum wrote: On Tue, Nov 3, 2009 at 9:37 AM, "Martin v. Löwis" wrote: (and no, adding things like nonlocal to 2.7 doesn't making porting of a real application or library any easier, since the existing application or library simply doesn't use that keyword. Agreed. In fact, no cha

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

James Y Knight wrote: If that happens, it's not true that there's *nowhere* to go. A solution would be to discard 3.x as a failed experiment, take everything that is useful from it and port it to 2.x, and simply continue development from the last 2.x release. And from there, features can be de

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

Glyph Lefkowitz wrote: For what it's worth, the official position of the Twisted project is not that we have "no plan" to move to Python 3. It's that our plan is to do exactly as Raymond suggests, and give the users a vote - in this case, you vote with your patches :). You probably will not

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

Zooko O'Whielacronx wrote: Folks: So, if you guys slip in your favorite new Python 3 feature into 2.7 and add a deprecation warning for your least favorite Python 2 misfeature, Just run with the -3 flag for warnings. Also see my response to Glyph. Terry Jan Reedy

Re: [Python-Dev] Retrieve an arbitrary element from a setwithoutremoving it

Eric Smith wrote: Raymond Hettinger wrote: Summarizing my opposition to a new set method: 1) there already are at least two succinct ways to get the same effect 2) those ways work with any container, not just sets 3) set implementations in other languages show that this isn't needed. 4) there is

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

John Arbash Meinel wrote: He wanted to introduce a moratorium at least partially because he was tired of endless threads about anonymous code blocks, etc. Which aren't going to be included in the language anyway, so he may as well make a point to say "and neither will anything else for a while".

Re: [Python-Dev] IDLE as default Python editor (Was: [pygame] Python IDE for windoz)

anatoly techtonik wrote: Hello, Quite an interesting question recently popped up in pygame community that I'd like to ask to Python developers. How many of you use IDLE? I do, both shell and editor (for Python code). What's wrong with it? See tracker. I agree that discussion of alternati

Re: [Python-Dev] decimal.py: == and != comparisons involving NaNs

Mark Dickinson wrote: That's because you're creating two different float nans. Compare with: Python 3.2a0 (py3k:76132M, Nov 6 2009, 14:47:39) [GCC 4.2.1 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. nan = float('nan') d = {nan: 10, 0: 20} nan i

Re: [Python-Dev] PyPI comments and ratings, *really*?

Barry Warsaw wrote: On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote: Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until A> I find the time to contribute to make it better or B> It changes. That's distres

Re: [Python-Dev] PyPI comments and ratings, *really*?

Guido van Rossum wrote: On Thu, Nov 12, 2009 at 10:30 AM, Terry Reedy wrote: Barry Warsaw wrote: On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote: Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until

[Python-Dev] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)

Martin v. Löwis wrote: This is indeed intentional: people like you won't upload packages to PyPI, nor will they take part in the rating system, as both require a PyPI account. Why? I already have python tracker account and a python wiki account which is already 2 too many. The latter was a pa

Re: [Python-Dev] buildtime vs runtime in Distutils

Christian Heimes wrote: Tarek Ziadé wrote: Hello, http://bugs.python.org/issue4359 reminds me that Distutils reads build files like Makefile or pyconfig.h to get some environment variables through the sysconfig module at *runtime*. This cannot work on all platforms, when our Makefile is not sh

Re: [Python-Dev] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)

Martin v. Löwis wrote: Why? I already have python tracker account and a python wiki account which is already 2 too many. The latter was a pain because the site lost my registration and as of a year ago, the registration process was broken. I would much prefer just one python site registration.

Re: [Python-Dev] global statements outside functions/methods should raise SyntaxError

Ezio Melotti wrote: Python currently accepts global statements at the top level: I opened an issue on the tracker (http://bugs.python.org/issue7329) and Benjamin suggested to discuss this here. The test he mentioned is in test_global.py: def test4(self): prog_text_4 = """\ global x x

Re: [Python-Dev] Static analysis of CPython using coccinelle/spatch

A.M. Kuchling wrote: On Mon, Nov 16, 2009 at 03:27:53PM -0500, David Malcolm wrote: Has anyone else looked at using Coccinelle/spatch[1] on CPython source code? For an excellent explanation of Coccinelle, see . For those who have not looked, Coccinelle means

Re: [Python-Dev] PEP 391 ready for review

Vinay Sajip wrote: Full View PEP 391 is, I believe, ready for review. http://www.python.org/dev/peps/pep-0391/ This is my first reading of this. Comments: nit: I believe "both of these serialization formats allow deserialization of Python dictionaries." should be "... to Python dictionaries

Re: [Python-Dev] Sort out formatting differences in decimal and float

Nick Coghlan wrote: s...@pobox.com wrote: My apologies if I don't understand some amazing generality about format() format("Header", '=^20s') '===Header===' "Format a single object {0!r}, multiple times in a single string. Year: {0.year}; Month: {0.month}; Day: {0.day}; Formatte

Re: [Python-Dev] Proposing PEP 386 for addition

Tarek Ziadé wrote: Hello, On behalf of the Distutils-SIG, I would like to propose PEP 386 for inclusion in the sdtlib, and have a final discussion here on Python-dev. http://www.python.org/dev/peps/pep-0386 Some English copy editor comments: "and it will optionally allow to use that field" I

Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?

Lennart Regebro wrote: On Thu, Dec 10, 2009 at 00:47, Paul Moore wrote: When the IGNORE_EXCEPTION_DETAIL doctest option is is specified, everything following the leftmost colon is ignored. """ Note that the difference is *before* the leftmost colon. On Thu, Dec 10, 2009 at 00:49, Ian Bicki

Re: [Python-Dev] Pronouncement on PEP 389: argparse?

On 12/14/2009 1:43 PM, Steven Bethard wrote: On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard wrote: So there wasn't really any more feedback on the last post of the argparse PEP other than a typo fix and another +1. I just converted a s

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

On 12/27/2009 7:48 PM, Antoine Pitrou wrote: Tarek Ziadé gmail.com> writes: This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2". How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 itself?

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

On 1/10/2010 8:44 PM, Neil Schemenauer wrote: On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote: I don't think ending the 2.x series at 2.7 makes it look bad compared to 3.2; it's simply the end of a development line like any other software project. I suspect 2.7 will have a protracte

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

On 1/12/2010 5:04 PM, "Martin v. Löwis" wrote: But you won't *have* fewer differences. Just because your code runs on 2.8 doesn't mean it will stop running on 2.3 (if you have a need for that). This doesn't get you any closer - you can't use any of the 2.8 features as long as you have to support

Re: [Python-Dev] regex module

On 1/12/2010 5:10 PM, MRAB wrote: Hi all, I'm back on the regex module after doing other things and I'd like your opinion on a number of matters: Firstly, the current re module has a bug whereby it doesn't split on zero-width matches. The BDFL has said that this behaviour should be retained by

Re: [Python-Dev] Fwd: Download Page - AMD64

On 1/13/2010 2:13 PM, "Martin v. Löwis" wrote: I think we should use whatever is most informative and least confusing to our users - we owe our allegiance to them and not to a processor vendor. And why do you think this is x86-64? I do not believe I have personally seen, or at least noticed,

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Some comments from a non-developer: The proposal to add this to 3.x seems a bit premature until you have a version that runs with 3.x. Not that I expect that to be a problem though. If CPython development moves to distributed hg, the notion of 'blessed' branches (other than the PSF release br

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

On 1/23/2010 2:53 AM, "Martin v. Löwis" wrote: So for the limited case of text IO, Python 3.x now makes a guess. However, this guess is not in the face of ambiguity: it is the locale that the user (or his administrator) has selected, That is a mistaken assumption for many. I have never, that I

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

On 1/23/2010 7:53 AM, Antoine Pitrou wrote: Terry Reedy udel.edu> writes: If the current guess is based on a mistaken assumption -- that it is giving the user what the user asked for -- it might be reconsidered. I personally would prefer that the default file encoding for Python 3 be ut

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On 1/25/2010 9:32 PM, Nick Coghlan wrote: However, as Cameron pointed out, the O() value for an operation is an important characteristic of containers, and having people get used to an O(1) list.pop(0) in CPython could create problems not only for other current Python implementations but also fo

Re: [Python-Dev] Summary of 2 years of Python fuzzing

On 1/25/2010 5:34 PM, Victor Stinner wrote: It looks like fuzzing bugs are not always appreciated by developers, maybe because they are always "borderline" cases (not "realist"). People grumble, sometimes, even when quietly appreciative. Sometimes, even if I write a patch, an unit test, expl

Re: [Python-Dev] Summary of 2 years of Python fuzzing

On 1/26/2010 2:27 AM, Terry Reedy wrote: On 1/25/2010 5:34 PM, Victor Stinner wrote: It looks like fuzzing bugs are not always appreciated by developers, maybe because they are always "borderline" cases (not "realist"). People grumble, sometimes, even when quietly appre

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On 1/26/2010 7:51 AM, Steve Howell wrote: From: Nick Coghlan Steve, I suggest creating a new issue at bugs.python.org to track your proposal rather than sending diffs to the list. I was about to suggest the same thing. Even if your final patch is not currently accepted, it will remain on the

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/26/2010 6:17 PM, Collin Winter wrote: 70MB of the increase was indeed debug information. Since the Linux distros that I checked ship stripped Python binaries, I've stripped the Unladen Swallow binaries as well, and while the size increase is still significant, it's not as large as it once w

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On 1/28/2010 6:30 PM, Josiah Carlson wrote: I would also point out that the way these things are typically done is that programmers/engineers have use-cases that are not satisfied by existing structures, they explain the issues they have with existing structures, and they propose modifications.

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 4:19 PM, Collin Winter wrote: On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: Agreed. We originally switched Unladen Swallow to wordcode in our 2009Q1 release, and saw a performance improvement from this across the board. We switched back to bytecode for the JIT compiler to

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 5:55 PM, Collin Winter wrote: Hey Terry, On Fri, Jan 29, 2010 at 2:47 PM, Terry Reedy wrote: Several years, there was serious consideration of switching to a registerbased vm, which would have been even more of a change. Since I learned 1.4, Guido has consistently insisted that

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 6:45 PM, "Martin v. Löwis" wrote: On Windows, would a C extension author be able to distribute a single binary (bdist_wininst/bdist_msi) which would be compatible with with-LLVM and without-LLVM builds of Python? When PEP 384 gets implemented, you not only get that, but you will al

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On 1/31/2010 8:58 AM, Vitor Bosshard wrote: Having one single pyr (or__pycache__ or whatever it's called) subfolder per folder is an easy to understand, solid solution. As a user who browses directories to see what is there and to find files to open and look at, I would like this. The near-du

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On 1/31/2010 8:34 AM, Nick Coghlan wrote: Georg Brandl wrote: +1. Having a single (visible) __pyr__ directory is much less clutter than multiple .pyc files anyway. Also, don't forget Windows users, for whom the dot convention doesn't mean anything. I must admit I quite like the __pyr__ dire

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On 1/31/2010 4:26 PM, Tim Delaney wrote: The pyc/pyo files are just an optimisation detail, and are essentially temporary. The .pycs for /Lib and similar are*not* temporarily in the sense you are using. They are effectively permanent for as long as the version is installed. They should *n

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 2/1/2010 1:32 PM, Collin Winter wrote: Hey MA, On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg wrote: BTW: Some years ago we discussed the idea of pluggable VMs for Python. Wouldn't U-S be a good motivation to revisit this idea ? We could then have a VM based on byte code using a stack machi

Re: [Python-Dev] Rational for PEP 3147 (PYC Respository Directories)

On 2/3/2010 12:35 PM, Neil Schemenauer wrote: Hi Barry, Thanks for doing the work of writing a PEP. The rational section could use some strengthing, I think. Who is benefiting from this feature? The original proposal of changing .pyc to a directory would be negative to me so I would not use

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On 2/8/2010 7:54 AM, Nick Coghlan wrote: Ron Adam wrote: To tell the truth in most cases I hardly notice the extra time the first run takes compared to later runs with the precompiled byte code. Yes it may be a few seconds at start up, but after that it's usually not a big part of the execution

Re: [Python-Dev] Add alternate float formatting styles to new-style formatting: allowed under moratorium?

On 2/24/2010 8:13 AM, Eric Smith wrote: http://bugs.python.org/issue7094 proposes adding "alternate" formatting [1] to floating point new-style formatting (float.__format__ and probably Decimal.__format__). I'd like to add this to make automated translation from %-formatting strings to str.format

Re: [Python-Dev] Status of PEP 381

On 3/1/2010 2:45 PM, Jacob Kaplan-Moss wrote: Hey folks -- Can someone point me to some information on what's going on with PEP 381 (PyPI mirroring)? There's a bunch of XXX'd material, and it doesn't appear that pypi.python.org implements the statistics or providing parts. I'd be willing -- hap

Re: [Python-Dev] doctest, unicode repr, and 2to3

On 3/4/2010 11:11 PM, "Martin v. Löwis" wrote: Johan Harjano ran into an interesting problem when trying to run the Django test suite under Python 3.1. Django has doctests of the form a6.headline u'Default headline' Even when converting the doctest with 2to3, the expected output is unmodifie

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 3/8/2010 6:14 AM, Nick Coghlan wrote: P.J. Eby wrote: I'm +1 on adding a nice task queuing system, -1 on calling it by any other name. ;-) As Guido said, let's call the nice task queuing system "futures" and I was confused by 'futures' also until Philip explained it as task-queue or tas

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 3/6/2010 4:20 AM, Brian Quinlan wrote: On 6 Mar 2010, at 03:21, Daniel Stutzbach wrote: On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan mailto:br...@sweetapp.com>> wrote: import futures +1 on the idea, -1 on the name. It's too similar to "from __future__ import ...". Also, the PEP sh

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 3/8/2010 4:39 PM, Greg Ewing wrote: Terry Reedy wrote: Looking more close, I gather that the prime results will be printed 'in order' (waiting on each even if others are done) while the url results will be printed 'as available'. Seems to me that if you care about the

Re: [Python-Dev] Patch to telnetlib.py

On 3/13/2010 12:24 PM, gregory dudek wrote: The Telnet module telnetlib.py can be very slow -- unusably slow -- for large automated data transfers. There are typically done in raw mode. The attached patch Please submit to the tracker. If there is an existing issue, attach it to that.

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

On 3/17/2010 1:09 PM, Guido van Rossum wrote: Ok, I'll try to stay out of the discussion of which solution is best of our users, and if the outcome is that mixed operations in general are bad but mixed comparisons are good, I'll trust you. However I want to reiterate that you really shouldn't im

[Python-Dev] Joel Spolsky on Mercurial

In what might be his last Joel on Software post (for awhile, at least) http://www.joelonsoftware.com/items/2010/03/17.html Summary: Early 2009: Joel disses DVCSes. His programmers switch from subversion to hg. Joel grumbles. His programmers develop an hg-related product. Joel takes a better loo

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

On 3/18/2010 5:48 PM, Nick Coghlan wrote: Mark Dickinson wrote: Could everyone live with making float<->Decimal comparisons raise an exception in 2.7? I could, with the caveat that *if* this causes problems for real world code, then changing it to produce the correct answer (as per your patch)

<    7   8   9   10   11   12   13   14   15   16   >