Re: [Python-Dev] [Python-ideas] minmax() function returning (minimum, maximum) tuple of a sequence

max(), namely that it will take either a single iterable argument or multiple arguments.) I've experimented with minmax() myself. Not surprisingly, the performance of a pure Python version doesn't even come close to the built-ins. I&#x

Re: [Python-Dev] Patch making the current email package (mostly) support bytes

s at a conference, than with the feet > of the masses whose votes will ultimately decide 3.X's fate. I don't think anyone has ever suggested change for change's sake. If they have, I'd love to read the PEP for it. -- Steven D'Aprano _

Re: [Python-Dev] A new warning category?

by line number and filename doesn't make sense. So a new > category would be useful in order to allow defining specific rules. Sounds like a reasonable suggestion to me. > Do you think it would go against the moratorium? It's not clear to me one way or the other, but I

Re: [Python-Dev] Fwd: [Python-ideas] stats module Was: minmax() function ...

e time > to develop it. [...] > I think the creativity and energy of this group is much better > directed at building a quality stats module (perhaps with some R-like > capabilities). +1 Are you still interested in working on it, or is this a subtle hint that somebody else s

Re: [Python-Dev] Continuing 2.x

Antoine Pitrou wrote: Even if there were no trademark, I think it would be wrong for a separate project to adopt the same name without agreement from the original group of contributors. I have never seen a fork which didn't change the name of the project. +1 -- Steven ___

Re: [Python-Dev] Cleaning-up the new unittest API

Raymond Hettinger wrote: The API for the unittest module has grown fat (the documentation is approaching 2,000 lines and 10,000 words like a small book). I think we can improve learnability by focusing on the most important parts of the API. I would like to simplify and clean-up the API for t

Re: [Python-Dev] Pickle alternative in stdlib (Was: On breaking modules into packages)

Nick Coghlan wrote: As a tool for communicating between different instances of the *same* version of Python though, pickle is fine. I'm using pickle to pass a list and dict of floats and strings from Python 2.6 to 3.1. I've never had any problems with it. Am I living in a state of sin or is

Re: [Python-Dev] Python-3 transition in Arch Linux

James Y Knight wrote: But the previous consensus (at least, as I, and presumably many other people understood it) was that python2 would remain the owner of the name "/usr/bin/python" for the indefinite future, and python3 would be invoked with /usr/bin/python3. Given that, it's not at all clea

Re: [Python-Dev] Breaking undocumented API

Ron Adam wrote: My understanding is that anything with an actual docstring is part of the public API. I frequently add docstrings to _private functions. Just because it is private doesn't mean I don't want documentation for it, and it is very handy for running doctests. Yes, I test my inte

Re: [Python-Dev] Breaking undocumented API

Nick Coghlan wrote: My personal opinion is that we should be trying to get the standard library to the point where __all__ definitions are unnecessary - if a name isn't in __all__, it should start with an underscore (and if that is true, then the __all__ definition becomes effectively redundant)

Re: [Python-Dev] Breaking undocumented API

Ben Finney wrote: I don't know about Guido, but I'd be −1 on suggestions to add more normative information to PEP 7, PEP 8, PEP 257, or any other established style guide PEP. I certainly don't want to have to keep going back to the same documents frequently just to see if the set of recommendati

Re: [Python-Dev] Breaking undocumented API

Łukasz Langa wrote: Mutating PEP8 is bad form. We fight mercilessly over source code backwards compatibility so I think PEPs should be taken just as seriously in that regard. There's no comparison between the two. If you change your library's API -- not "source code", it doesn't matter if t

Re: [Python-Dev] Breaking undocumented API

Nick Coghlan wrote: The policy we're aiming to clarify here is what we should do when we come across standard library APIs that land in the grey area, with there being two appropriate ways to deal with them: 1. Document them and make them officially public 2. Deprecate the public names and make

Re: [Python-Dev] constant/enum type in stdlib

Antoine Pitrou wrote: Constants = make_constants('Constants', 'SOME_CONST OTHER_CONST', values=range(1, 3)) Again, auto-enumeration is useless since it's trivial to achieve explicitly. That doesn't make auto-enumeration "useless". Unnecessary, perhaps, but not u

Re: [Python-Dev] constant/enum type in stdlib

Antoine Pitrou wrote: Python already has an enumeration capability. It's called range(). There's nothing else that C enums have. AFAICT, neither do enums in other mainstream languages (assuming they even exist; I don't remember Perl, PHP or Javascript having anything like that, but perhaps I'm m

Re: [Python-Dev] constant/enum type in stdlib

Nick Coghlan wrote: On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord wrote: Based on a non-exhaustive search, Python standard library modules currently using integers for constants: Thanks for that review. I think following up on the "NamedConstant" idea may make more sense than pursuing enums

Re: [Python-Dev] [Preview] Comments and change proposals on documentation

Nick Coghlan wrote: On Thu, Nov 25, 2010 at 6:24 AM, Georg Brandl wrote: Hi, at , you can look at a version of the 3.2 docs that has the upcoming commenting feature. JavaScript is mandatory. Very nice! I'm not sure what to do about the discoverability of the

Re: [Python-Dev] [Preview] Comments and change proposals on documentation

Georg Brandl wrote: Am 27.11.2010 23:11, schrieb Steven D'Aprano: I wasn't able to find a comment bubble that contained anything, so I don't know what sort of information you expect them to contain -- every one I tried said "0 comments". Maybe you should have tri

Re: [Python-Dev] constant/enum type in stdlib

Michael Foord wrote: Another 'optional' feature I omitted was Phillip J. Eby's suggestion / requirement that named values be pickleable. Email is clunky for handling this, is there enough support (there is still some objection that is sure) to revive the PEP or create a new one? I think it d

Re: [Python-Dev] Python and the Unicode Character Database

Martin v. Löwis wrote: float('١٢٣٤.٥٦') 1234.56 I think it's a bug that this works. The definition of the float builtin says [...] I think that's a documentation bug rather than a coding bug. If Python wishes to limit the digits allowed in numeric *literals* to ASCII 0...9, that's one thin

Re: [Python-Dev] Python and the Unicode Character Database

Alexander Belopolsky wrote: Two recently reported issues brought into light the fact that Python language definition is closely tied to character properties maintained by the Unicode Consortium. [1,2] For example, when Python switches to Unicode 6.0.0 (planned for the upcoming 3.2 release), we w

Re: [Python-Dev] Python and the Unicode Character Database

Alexander Belopolsky wrote: Speaking of YAGNI, does anyone want to defend complex('١٢٣٤.٥٦j') 1234.56j *If* we allow float('١٢٣٤.٥٦') (as we currently do, but is being disputed by some), then we should allow complex('١٢٣٤.٥٦j'). It would be silly for complex to be more restrictive than fl

Re: [Python-Dev] Python and the Unicode Character Database

haiyang kang wrote: hi, I agree with this. I never seen any man in China using chinese number literals (at least two kinds:一, 壹, same meaning with 1) in Python program, except UI output. They can do some mappings when want to output these non-ascii numbers. Example: if 1: print "一"

Re: [Python-Dev] Python and the Unicode Character Database

Stephen J. Turnbull wrote: Lennart Regebro writes: > *I* think it is more important. In python 3, you can never ever assume > anything is ASCII any more. Sure you can. In Python program text, all keywords will be ASCII (English, even, though it may be en_NL.UTF-8) for the forseeable future.

Re: [Python-Dev] Python and the Unicode Character Database

Martin v. Löwis wrote: Am 30.11.2010 23:43, schrieb Terry Reedy: On 11/30/2010 3:23 AM, Stephen J. Turnbull wrote: I see no reason not to make a similar promise for numeric literals. I see no good reason to allow compatibility full-width Japanese "ASCII" numerals or Arabic cursive numerals in

Re: [Python-Dev] Python and the Unicode Character Database

Martin v. Löwis wrote: I think the OP (haiyang kang) already indicated that he finds it quite unlikely that anybody would possibly want to enter that. Who's talking about *entering* it into the program at a keyboard directly, though? Input to a program can come from all kinds of crazy sources. J

Re: [Python-Dev] Python and the Unicode Character Database

Martin v. Löwis wrote: And here, my observation stands: if they wanted to, they currently couldn't - at least not for real numbers (and also not for integers if they want to use grouping). So the presumed application of this feature doesn't actually work, despite the presence of the feature it wa

Re: [Python-Dev] Python and the Unicode Character Database

Martin v. Löwis wrote: Then these users should speak up and indicate their need, or somebody should speak up and confirm that there are users who actually want '١٢٣٤.٥٦' to denote 1234.56. To my knowledge, there is no writing system in which '١٢٣٤.٥٦e4' means 12345600.0. I'm not sure what you're

Re: [Python-Dev] Python and the Unicode Character Database

Stephen J. Turnbull wrote: Steven D'Aprano writes: > With full respect to haiyang kang, hear-say from one person can hardly > be described as "strong" evidence That's *disrespectful* nonsense. What Haiyang reported was not hearsay, it's direct observation

Re: [Python-Dev] gc ideas -- sparse memory

James Y Knight wrote: On Dec 3, 2010, at 10:50 PM, Terry Reedy wrote: On 12/3/2010 7:46 PM, James Y Knight wrote: Sure they are. This is what Java provides you, for example. If you have fixed, but potentially non-unique ids (in Java you get this using "identityHashCode()"), you can still make

Re: [Python-Dev] gc ideas -- sparse memory

Martin v. Löwis wrote: I'm afraid I don't follow you. Unless you're suggesting some sort of esoteric object system whereby objects *don't* have identity (e.g. where objects are emergent properties of some sort of distributed, non-localised "information"), any object naturally has an identity -- i

Re: [Python-Dev] futures API

Brian Quinlan wrote: On Dec 11, 2010, at 6:44 AM, Thomas Nagy wrote: I have also observed a minor performance degradation with the executor replacement (3 seconds for 5000 work items). The amount of work items processed by unit of time does not seem to be a straight line: http://www.freehac

Re: [Python-Dev] configparser 1.1 - one last bug fix needed

Antoine Pitrou wrote: On Tue, 14 Dec 2010 10:20:04 +1000 Nick Coghlan wrote: +1 from me. If anyone complains too much, perhaps we can offer to retain the old ConfigParser as "_BuggyConfigParser"? (that idea is only partially tongue-in-cheek...) Or we can put it in the "buggy" module which r

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

Antoine Pitrou wrote: For a non-native English speaker, 'a' and 'b' don't evoke 'after' and 'before' but simply the first two letters of the latin alphabet, and their ordering is therefore obvious with respect to function arguments. It's not just non-native English speakers either. I too think

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

Guido van Rossum wrote: On Tue, Jan 4, 2011 at 2:49 AM, Michael Foord wrote: I think someone else pointed this out, but replacing builtins externally to a module is actually common for testing. In particular replacing the open function, but also other builtins, is often done temporarily to repl

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

Guido van Rossum wrote: On Tue, Jan 4, 2011 at 1:50 PM, Steven D'Aprano wrote: I've been known to monkey-patch builtins in the interactive interpreter and in test code. One example that comes to mind is that I had some over-complicated recursive while loop (!), and I wanted to work o

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

s...@pobox.com wrote: I realize the world is passing me by and that I'm rapidly turning into a dinosaur w.r.t. distributed version control, but as you write/update the developer's guide remember that proficiency in Python does not necessarily equate to proficiency in version control systems, esp

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

Antoine Pitrou wrote: On Thu, 20 Jan 2011 01:23:26 +1100 Steven D'Aprano wrote: s...@pobox.com wrote: I realize the world is passing me by and that I'm rapidly turning into a dinosaur w.r.t. distributed version control, but as you write/update the developer's guide remember t

Re: [Python-Dev] Byte code arguments from two to one byte: did anyone try this?

Jurjen N.E. Bos wrote: I was impressed by the optimizations already in there, but I still dare to suggest an optimization that from my estimates might shave off a few cycles, speeding up Python about 5%. The idea is simple: change the byte code argument values from two bytes to one. Interest

Re: [Python-Dev] [Python-checkins] r88331 - in python/branches/py3k/Doc/howto: index.rst pyporting.rst

Nick Coghlan wrote: On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon wrote: +Capturing the Currently Raised Exception + +One change between Python 2 and 3 that will require changing how you code is +accessing the currently raised exception. In Python 2 the s

Re: [Python-Dev] set iteration order

Hagen Fürstenau wrote: Code with any dependence on the iteration order of unordered collections (other than the guarantee that d.keys() and d.values() match at any given time as long as d is unchanged) is buggy. It's not a matter of dependence on iteration order, but of reproducibility (in my c

Re: [Python-Dev] r88676 - peps/trunk/pep-0385.txt

Antoine Pitrou wrote: Le lundi 28 février 2011 à 13:56 -0600, Benjamin Peterson a écrit : 2011/2/28 Antoine Pitrou : On Mon, 28 Feb 2011 13:36:11 -0500 Terry Reedy wrote: + an existing branch. The pusher then has to merge the superfetatory heads 'superfetatory'? I have no idea of what this

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

Jérôme Radix wrote: Hello, Defensive programming will force you to do things like : import sys if sys.version[0] == '2': Really? Do you already do this? if sys.version < '2.2': result = apply(func, arguments) else: result = func(*arguments) And if so, have you tested it in Python

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

James Y Knight wrote: I suspect he's saying it'd be better if the time didn't come (if so, I'd agree). Python3 *is* unfortunately a new and incompatible programming language, it makes sense for it to have it have its own interpreter name. Oh come on, there's like three incompatibilities vers

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

Steven D'Aprano wrote: Jérôme Radix wrote: Hello, Defensive programming will force you to do things like : import sys if sys.version[0] == '2': Really? Do you already do this? if sys.version < '2.2': result = apply(func, arguments) else: result = func(*

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

Westley Martínez wrote: On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote: On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley wrote: That way, if the sysadmin does decide to replace the installed "python" file, he can do so without inadvertently deleting the previously installed binary. Nit

Re: [Python-Dev] PEP 395: Module Aliasing

Fred Drake wrote: On Fri, Mar 4, 2011 at 10:59 AM, wrote: Something to consider here is how this will interact with Python files which are _not_ modules. I'm a little uneasy about having sys.modules["trial"] refer to the module defined by /usr/bin/trial. I've long held the position that mod

Re: [Python-Dev] PEP 395: Module Aliasing

Nick Coghlan wrote: Fixing direct execution inside packages --- To fix this problem, it is proposed that an additional filesystem check be performed before proceeding with direct execution of a ``PY_SOURCE`` or ``PY_COMPILED`` file that has been named on the

Re: [Python-Dev] Vagaries of "their" in English (was Re: Support the /usr/bin/python2 symlink upstream)

Daniel A. Welty wrote: * "they" and "their" are plural, and should never be used in the singular. Thank you for sharing your option here, but you are not a linguist and you are simply wrong. At least two people in this thread have already linked to Wikipedia's article on singular-they, wh

Re: [Python-Dev] Vagaries of "their" in English (was Re: Support the /usr/bin/python2 symlink upstream)

Westley Martínez wrote: I believe singular they should not be used in formal writing. So what if you use it in an email? If you, personally, dislike it, then don't use it. But if you (generic you) say that it is grammatically incorrect to do so, then you are simply *wrong*. Some things are a

Re: [Python-Dev] Callable, non-descriptor class attributes.

Thomas Wouters wrote: One of the things brought up at the language summit (and I believe at the VM summit, although I wasn't there) was the unpredictable behaviour of callables turning into methods when they're class attributes. [...] 1. Make staticmethod a callable object directly (it isn't,

Re: [Python-Dev] Callable, non-descriptor class attributes.

Guido van Rossum wrote: +1 on making staticmethods callable. I would have found that useful in the past. IIUC Thomas found that this breaks some current use of staticmethod. As I understand it, Thomas found that having staticmethod callable AND have staticmethod.__get__ return self breaks

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

Cesare Di Mauro wrote: Also, optimizations can be done not only for numbers, but even for tuples, lists, dictionaries, and... slices (pag. 22). See pages 21-24 of this For the record, constant-folding

Re: [Python-Dev] Callable, non-descriptor class attributes.

Thomas Wouters wrote: I would much rather loudly warn people to fix their code, instead of forcing other implementations (and, more importantly to me personally, future CPython changes :) to deal with the distinction forever. But if we declare a wrapper to be the right way to deal with this, let

Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)

Fredrik Johansson wrote: Consider sorting a list of pairs representing fractions. This can be done easily in Python 2.x with the comparison function lambda (p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times faster than using fractions.Fraction as a key function. [steve@sylar ~]

[Python-Dev] Conflict between time docs and timeit

I see that the documentation for the time module has this to say about time.clock: On Unix, return the current processor time as a floating point number expressed in seconds. The precision, and in fact the very definition of the meaning of “processor time”, depends on that of the

Re: [Python-Dev] Hg: inter-branch workflow

Tim Delaney wrote: You'd end up using more horizontal space, but we all seem to have widescreen monitors these days. Not even close to "we all". -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pyt

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

anatoly techtonik wrote: I didn't touch Python3 until PyCon, and my first user experience is not really good. I've got a feeling that Python3 became more ugly, because it doesn't allow me to think about the logic anymore, and requires more low-level workarounds even for basic user input/output.

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

Greg Ewing wrote: Steven D'Aprano wrote: The main one that comes to my mind is that other than looping, any time I want to process dict.items() etc I often need to call list() first. I don't think that's such a bad thing. It makes it clear that you're performing a more

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

Lennart Regebro wrote: On Tue, Mar 22, 2011 at 22:12, Steven D'Aprano wrote: The main one that comes to my mind is that other than looping, any time I want to process dict.items() etc I often need to call list() first. "Process" no. If you want it to be a list, yes. This is b

Re: [Python-Dev] python and super

Ricardo Kirkner wrote: Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain

Re: [Python-Dev] python and super

Ricardo Kirkner wrote: I have a TestCase class, which inherits from both Django's TestCase and from some custom TestCases that act as mixin classes. So I have something like class MyTestCase(TestCase, Mixin1, Mixin2): ... now django's TestCase class inherits from unittest2.TestCase, which w

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

Brett Cannon wrote: In the grand python-dev tradition of "silence means acceptance", I consider this PEP finalized and implicitly accepted. How long does that silence have to last? I didn't notice a definition of what counts as "100% branch coverage". Apologies if I merely failed to notice it

Re: [Python-Dev] python and super

Michael Foord wrote: On 15/04/2011 02:23, Steven D'Aprano wrote: [...] If we treat django's failure to use super as a bug, you want the Python language to work-around that bug so that: What you say (that this particular circumstance could be treated as a bug in django) is tru

Re: [Python-Dev] Allowing import star with namespaces

Brendan Moloney wrote: We all know that doing: from pkg import * is bad because it obliterates the 'pkg' namespace. So why not allow something like: I don't quite know what you mean by obliterating the pkg namespace, but if my guess is correct, you're wrong. One of the problems with impor

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Guido van Rossum wrote: Maybe we should just call off the odd NaN comparison behavior? This doesn't solve the broader problem that *any* type might deliberately define non-reflexive equality, and therefore people will still be surprised by >>> x = SomeObject() >>> x == x False >>> [x] ==

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Terry Reedy wrote: On 4/27/2011 2:41 PM, Glenn Linderman wrote: One issue that I don't fully understand: I know there is only one instance of None in Python, but I'm not sure where to discover whether there is only a single, or whether there can be multiple, instances of NaN or Inf. I am sure

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Greg Ewing wrote: Guido van Rossum wrote: Maybe we should just call off the odd NaN comparison behavior? That's probably as good an idea as anything. The weirdness of NaNs is supposed to ensure that they propagate through a computation as a kind of exception signal. But to make that work pro

Re: [Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

Mark Shannon wrote: Related to the discussion on "Not a Number" can I point out a few things that have not be explicitly addressed so far. The IEEE standard is about hardware and bit patterns, rather than types and values so may not be entirely appropriate for high-level language like Python.

Re: [Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

Mark Shannon wrote: Steven D'Aprano wrote: Mark Shannon wrote: Related to the discussion on "Not a Number" can I point out a few things that have not be explicitly addressed so far. The IEEE standard is about hardware and bit patterns, rather than types and values so may

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Alexander Belopolsky wrote: With the status quo in Python, it may only make sense to store NaNs in array.array, but not in a list. That's a bit extreme. It only gets you into trouble if you reason like this: >>> a = b = [1, 2, 3, float('nan')] >>> if a == b: ... for x,y in zip(a,b): ...

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Rob Cliffe wrote: To me the idea of non-reflexive equality (an object not being equal to itself) is abhorrent. Nothing is more likely to put off new Python users if they happen to run into it. I believe that's a gross exaggeration. In any case, that's just your opinion, and Python is hardly

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Guido van Rossum wrote: *If* my proposal gets accepted, there will be a blanket rule that no matter how exotic an type's __eq__ is defined, self.__eq__(self) (i.e., __eq__ called with the same *object* argument) must return True if the type's __eq__ is to be considered well-behaved; and Python c

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Steven D'Aprano wrote: I know thousands of words have been spilled on this, including many by myself, but I really believe this discussion is mostly bike-shedding. Hmmm... on reflection, I think I may have been a bit unfair. In particular, I don't mean any slight on any of the

Re: [Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

Terry Reedy wrote: I think the committee goofed -- badly. Statisticians used missing value indicators long before the committee existed. They has no problem thinking that the indicator, as an object, equaled itself. So one could write (and I often did through the 1980s) the equivalent of for

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

Nick Coghlan wrote: 1. IEEE754 is a value-based system, with a finite number of distinct NaN payloads 2. Python is an object-based system. In addition to their payload, NaN objects are further distinguished by their identity (infinite in theory, in practice limited by available memory). I argu

Re: [Python-Dev] Not-a-Number

Greg Ewing wrote: Taking a step back from all this, why does Python allow NaNs to arise from computations *at all*? The real question should be, why does Python treat all NANs as signalling NANs instead of quiet NANs? I don't believe this helps anyone. +Inf and -Inf are arguably useful elem

Re: [Python-Dev] Not-a-Number

Robert Kern wrote: On 4/28/11 8:44 PM, Steven D'Aprano wrote: Greg Ewing wrote: Taking a step back from all this, why does Python allow NaNs to arise from computations *at all*? The real question should be, why does Python treat all NANs as signalling NANs instead of quiet NANs? I

Re: [Python-Dev] Not-a-Number

Ben Finney wrote: Steven D'Aprano writes: Robert Kern wrote: On 4/28/11 8:44 PM, Steven D'Aprano wrote: The real question should be, why does Python treat all NANs as signalling NANs instead of quiet NANs? I don't believe this helps anyone. Actually, Python treats all NaN

Re: [Python-Dev] more timely detection of unbound locals

Eli Bendersky wrote: Hi all, It's a known Python gotcha (*) that the following code: x = 5 def foo(): print(x) x = 1 print(x) foo() Will throw: UnboundLocalError: local variable 'x' referenced before assignment I think part of the problem is that UnboundLocalError is a ja

Re: [Python-Dev] more timely detection of unbound locals

Eli Bendersky wrote: I think you are making an unwarranted assumption about what is "more expected". I presume you are thinking that the expected behaviour is that foo() should: print global x (5) assign 1 to local x print local x (1) If we implemented this change, there would be no more questi

Re: [Python-Dev] more timely detection of unbound locals

Nick Coghlan wrote: Personally, I would just add "in current scope" to the existing error message for the unbound local case (and potentially collapse the exception hierarchy a bit by setting UnboundLocalError = NameError). -0 That was the case prior to Python 2.0. Reverting is potentially a

Re: [Python-Dev] The socket HOWTO

Antoine Pitrou wrote: On Mon, 06 Jun 2011 10:33:14 +0200 "Martin v. Löwis" wrote: [...] How can you make such claims when several people have indicated that the howto *actually* helped them? The point here is that the examples in that document are very poor (the only substantial example actu

Re: [Python-Dev] cpython: Remove some extraneous parentheses and swap the comparison order to

Terry Reedy wrote: On 6/7/2011 5:35 PM, David Malcolm wrote: I know that this style is unpopular, but if it helps, try mentally pronouncing "==" in C as "is the value of". In this example, when I read that line, my mind is thinking: "if 'u' is the value of typecode" After ~12 years of

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

R. David Murray wrote: So, the correct generic term for something that can be accessed via attribute notation is attribute. The more specific term for an attribute that is a method is method. We don't currently have a more specific collective term for attributes that aren't methods. *That* is

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

Michael Foord wrote: What do you mean by "instances can have methods as instance attributes"? Once you attach a bound method directly to an instance it becomes a slightly different beast I think. (On top of which that is pretty rare behaviour.) >>> class C: ... def method(self, x): ...

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

Eli Bendersky wrote: Sure, but I'm still leery of two functions with the same name doing acting slightly differently. and then in a later post: As I mentioned elsewhere, it's not good practice to have two functions with the same name doing something slightly different, in different modules

Re: [Python-Dev] string representation of range in 3.0

Hi folks, Been lurking for a while, this is my first post. As I recall, this discussion was started because of concern that Python 3 had introduced features that made it less friendly to beginners. If I can quote Brad Miller: "Several new iterators have appeared in Python 3.0 that makes the

Re: [Python-Dev] PEP 8: Discourage named lambdas?

ery* easily miss the fact that TITLEPATTERN is a callable while glancing over the code (and be very confused if I later saw it being called or passed as a callback)", most people would dismiss the concern and tell me it was my problem. It certainly isn't a

Re: [Python-Dev] PEP 8: Discourage named lambdas?

ad out even longer, here's one example where I would use one: def parrot(args, transformation=None): if transformation is None: # Use an identity function. transformation = lambda x: x for arg in args: do_something_with(transformation(arg)) Does anybody have any c

Re: [Python-Dev] [Python-checkins] r62848 - python/trunk/Objects/setobject.c

on't want them to have access to is solved by the technical solution of file permissions and ACLs. I have no opinion on this specific problem, but it is equally fallacious to say that social problems_never_ have technical solutions as it is to say that they _al

Re: [Python-Dev] Adding start to enumerate()

On Mon, 12 May 2008 08:20:51 am Georg Brandl wrote: > I believe the following is a common use-case for enumerate() > (at least, I've used it quite some times): > > for lineno, line in enumerate(fileobject): > ... > > For this, it would be nice to have a start parameter for enumerate(). Why wo

Re: [Python-Dev] Adding start to enumerate()

nting seq[i-1] = foo(item) I never need to think about whether it is zero-based, one-based, or some other N-based counting, because it is always zero-based. -0 on any change to enumerate. -- Steven D'Aprano ___ Python-Dev mailing list Python-De

Re: [Python-Dev] Adding start to enumerate()

On Wed, 14 May 2008 05:01:20 am you wrote: > >  While slices are wonderfully useful things, they aren't panaceas. > >  They're not so useful with iterators, and they make a copy of the > > data, which can be problematic if there's a *lot* of it. > > That's why we have itertools.islice(). I always

Re: [Python-Dev] Conditional For Statements

On Mon, 19 May 2008 08:42:29 pm Lennart Regebro wrote: > How was it again? "One and only one way"? :-) Certainly not. What on earth gave you the idea that that ridiculous statement is a Python philosophy? I know some Perl developers like to contrast the supposed flexibility of Perl ("more than

Re: [Python-Dev] Iterable String Redux (aka String ABC)

(If you receive this twice, please excuse the duplicate email. User-error on my part, sorry.) On Wed, 28 May 2008 08:23:38 am Raymond Hettinger wrote: > A flatten() implementation doesn't really care about whether > an input is a string which supports all the string-like methods > such as capita

Re: [Python-Dev] Iterable String Redux (aka String ABC)

On Sat, 31 May 2008 12:48:41 am Armin Ronacher wrote: > Greg Ewing canterbury.ac.nz> writes: > > Well, I'm skeptical about the whole ABC thing in the > > first place -- it all seems very unpythonic to me. > > I think it's very pythonic and the very best solution to interfaces > *and* duck typing.

Re: [Python-Dev] converting the stdlib to str.format

On Wed, 4 Jun 2008 11:28:40 pm Nick Coghlan wrote: > > Not to mention that e.g. "%r" % s is much simpler than > > "{0!r}".format(s) (if I got the format spec right). > > repr(s) is even simpler :) Fair enough, and I see your smiley, but consider: "X %r X" % s "X {0!r} X".format(s) "X " + repr(

Re: [Python-Dev] converting the stdlib to str.format

On Thu, 5 Jun 2008 11:48:07 am Greg Ewing wrote: > Nick Coghlan wrote: > > - remove support for passing a single value to a format string > > without wrapping it in an iterable first > > But won't that clobber a large number of the simple > use cases that you want to keep %-formatting for? Yes, I

Re: [Python-Dev] converting the stdlib to str.format

On Thu, 5 Jun 2008 08:50:32 pm Paul Moore wrote: > On 05/06/2008, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > > Yes, I don't particularly see the advantage of writing: > > > > "spam %s spam" % (value,) > > > > over > > > > &q

<    8   9   10   11   12   13   14   15   16   >