On Sun, Mar 08, 2015 at 10:57:30PM -0700, Ryan Smith-Roberts wrote:
I suspect that you will find the Python community extremely conservative
about any changes to its sorting algorithm, given that it took thirteen
years and some really impressive automated verification software to find
this
On Sun, Mar 08, 2015 at 08:31:30PM -0700, Ethan Furman wrote:
When data is passed from Python to a native library (such as in an O/S
call), how does the unboxing of data types occur?
[...]
So the real question: anywhere in Python where an int is expected (for
lower-level API work), but not
On Fri, Mar 06, 2015 at 08:00:20PM -0500, Ron Adam wrote:
Have you considered doing this by having different magic numbers in the
.pyc file for standard, -O, and -O0 compiled bytecode files? Python
already checks that number and recompiles the files if it's not what it's
expected to be.
On Fri, Feb 13, 2015 at 06:03:35PM -0500, Neil Girdhar wrote:
I personally don't think this is a big enough issue to warrant any changes,
but I think Serhiy's solution would be the ideal best with one additional
parameter: the caller's type. Something like
def __make_me__(self, cls, *args,
On Sat, Feb 14, 2015 at 01:26:36PM -0500, Alexander Belopolsky wrote:
On Sat, Feb 14, 2015 at 7:23 AM, Steven D'Aprano st...@pearwood.info
wrote:
Why can't int, str, list, tuple etc. be more like datetime?
They are. In all these types, class methods call subclass constructors
On Thu, Feb 12, 2015 at 06:14:22PM -0800, Ethan Furman wrote:
On 02/12/2015 05:46 PM, MRAB wrote:
On 2015-02-13 00:55, Guido van Rossum wrote:
Actually, the problem is that the base class (e.g. int) doesn't know how
to construct an instance of the subclass -- there is no reason (in
On Wed, Jan 28, 2015 at 09:39:25AM -0500, Alan Armour wrote:
if you can do this
a chemical physics and element physics like everything from melting points
to how much heat you need to add two chemicals together
and physics like aerodynamics, space dynamics, and hydrodynamics etcetera
On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote:
So, I'm more than aware of how to write Python 2/3 compatible code. I've
ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at
work. I'm also aware of how much writing 2/3 compatible code makes me hate
Python as
On Sun, Nov 30, 2014 at 02:56:22PM -0500, Donald Stufft wrote:
As I mentioned in my other email, we’re already supporting two
different tools, and it’s a hope of mine to use this as a sort of
testbed to moving the other repositories as well.
If we go down this path, can we have some
On Tue, Dec 02, 2014 at 12:37:22AM +1100, Steven D'Aprano wrote:
[...]
It's one thing to say that using hg is discouraging contributors, and
that hg is much more popular.
/s/more/less/
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
I have some questions and/or issues with the PEP, but first I'm going to
add something to Nick's comments:
On Sun, Nov 30, 2014 at 11:12:17AM +1000, Nick Coghlan wrote:
Beyond that, GitHub is indeed the most expedient option. My two main
reasons for objecting to taking the expedient path are:
On Sun, Nov 30, 2014 at 11:07:57AM +1300, Greg Ewing wrote:
Nathaniel Smith wrote:
So pkgname/__new__.py might look like:
import sys
from pkgname._metamodule import MyModuleSubtype
sys.modules[__name__] = MyModuleSubtype(__name__, docstring)
To start with, the 'from
On Mon, Nov 24, 2014 at 10:22:54AM +1100, Chris Angelico wrote:
My point is that doing the same errant operation on a list or a dict
will give different exceptions. In the same way, calling next() on an
empty iterator will raise StopIteration normally, but might raise
RuntimeError instead.
On Sun, Nov 23, 2014 at 08:17:00AM -0800, Ethan Furman wrote:
While I am in favor of PEP 479, and I have to agree with Raymond that
this isn't pretty.
Currently, next() accepts an argument of what to return if the
iterator is empty. Can we enhance that in some way so that the
overall
On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote:
But I strongly believe that if we want to do the right thing for the
long term, we should switch to GitHub.
Encouraging a software, or social, monopoly is never the right thing for
the long term.
On Sun, Nov 23, 2014 at 06:08:07PM -0600, Brian Curtin wrote:
On Sun, Nov 23, 2014 at 5:57 PM, Steven D'Aprano st...@pearwood.info wrote:
I'm sure that we'll get *more* contributions, but will they be *better*
contributions?
I know that there are people who think that mailing lists
On Sat, Nov 22, 2014 at 12:53:41AM +1100, Chris Angelico wrote:
On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Also, the proposal breaks a reasonably useful pattern of calling
next(subiterator) inside a generator and letting the generator terminate
On Thu, Nov 20, 2014 at 11:36:54AM -0800, Guido van Rossum wrote:
[...]
That said, I think for most people the change won't matter, some people
will have to apply one of a few simple fixes, and a rare few will have to
rewrite their code in a non-trivial way (sometimes this will affect
clever
This is off-topic for this mailing list, as you know. There are some
mailing lists which approve of off-topic conversations, but this is not
one of those.
You could ask on the python-l...@python.org mailing list, where it will
still be off-topic, but the people there are more likely to answer.
On Fri, Sep 26, 2014 at 12:17:46AM +0200, Antoine Pitrou wrote:
On Thu, 25 Sep 2014 13:00:16 -0700
Bob Hanson d2mp...@newsguy.com wrote:
Critical bash vulnerability CVE-2014-6271 may affect Python on
*n*x and OSX:
[...]
See also:
http://adminlogs.info/2014/09/25/again-bash-cve-2014-7169/
On Fri, Sep 19, 2014 at 04:44:26AM -0400, Donald Stufft wrote:
On Sep 19, 2014, at 3:31 AM, Bohuslav Kabrda bkab...@redhat.com wrote:
Hi, as Fedora is getting closer to having python3 as a default, I'm
being more and more asked by Fedora users/contributors what'll
/usr/bin/python
On Fri, Sep 19, 2014 at 10:41:58AM -0400, Barry Warsaw wrote:
On Sep 19, 2014, at 10:23 AM, Donald Stufft wrote:
My biggest problem with ``python3``, is what happens after 3.9.
FWIW, 3.9 by my rough calculation is 7 years away.
That makes it 2021, one year after Python 2.7 free support
On Wed, Sep 17, 2014 at 09:21:56AM +0900, Stephen J. Turnbull wrote:
Guido's mantra is something like Python's str doesn't contain
characters or even code points[1], it contains code units.
But is that true? If it were true, I would expect to be able to make
Python text strings containing
On Wed, Sep 17, 2014 at 11:14:15AM +1000, Chris Angelico wrote:
On Wed, Sep 17, 2014 at 5:29 AM, R. David Murray rdmur...@bitdance.com
wrote:
Basically, we are pretending that the each smuggled
byte is single character for string parsing purposes...but they don't
match any of our parsing
On Wed, Sep 10, 2014 at 05:17:57PM +1000, Nick Coghlan wrote:
Since it may come in handy when discussing Why was Python 3
necessary? with folks, I wanted to point out that my article on the
transition to multilingual programming has now been reposted on the
Red Hat developer blog:
On Fri, Aug 22, 2014 at 11:53:01AM -0700, Chris Barker wrote:
The point is that if you are reading a file name from the system, and then
passing it back to the system, then you can treat it as just bytes -- who
cares? And if you add the byte value of 47 thing, then you can even do
basic path
On Fri, Aug 22, 2014 at 04:42:29AM +0200, Oleg Broytman wrote:
On Thu, Aug 21, 2014 at 05:30:14PM -0700, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
This brings up the other key problem. If file names are (almost)
arbitrary bytes, how do you write one to/read one from a text
On Sat, Aug 16, 2014 at 05:25:33PM +1000, Ben Finney wrote:
[...]
they would have already mistaken:
with a, b, c: ...
the same way. But they haven't.
Right. The presence or absence of parens make a big semantic difference.
from silly.mistakes.programmers.make import (
On Sun, Aug 17, 2014 at 11:28:48AM +1000, Nick Coghlan wrote:
I've seen a few people on python-ideas express the assumption that
there will be another Py3k style compatibility break for Python 4.0.
I used to refer to Python 4000 as the hypothetical compatibility break
version. Now I refer to
On Fri, Aug 15, 2014 at 02:08:42PM -0700, Ethan Furman wrote:
On 08/13/2014 10:32 AM, Steven D'Aprano wrote:
(2) Also note that *this is already the case*, since tuples are made by
the commas, not the parentheses. E.g. this succeeds:
# Not a tuple, actually two context managers.
with open
On Fri, Aug 15, 2014 at 08:29:09PM -0700, Ethan Furman wrote:
On 08/15/2014 08:08 PM, Steven D'Aprano wrote:
[...]
is a poor argument (that is, I'm disagreeing with it), since *single*
line parens-free with statements are already syntactically a tuple:
with spam, eggs, cheese
On Thu, Aug 14, 2014 at 02:26:29AM +1000, Chris Angelico wrote:
On Wed, Aug 13, 2014 at 11:11 PM, Isaac Morland ijmor...@uwaterloo.ca wrote:
While I would not claim a Python sandbox is utterly impossible, I'm
suspicious that the whole consenting adults approach in Python is
incompatible
On Wed, Aug 13, 2014 at 08:08:51PM +0300, yoav glazner wrote:
[...]
Just a thought, would it bit wierd that:
with (a as b, c as d): works
with (a, c): boom
with(a as b, c): ?
If this proposal is accepted, there is no need for the boom. The
syntax should allow:
# Without parens, limited to a
On Tue, Aug 12, 2014 at 10:28:14AM +1000, Nick Coghlan wrote:
On 12 Aug 2014 09:09, Allen Li cyberdup...@gmail.com wrote:
This is a problem I sometimes run into when working with a lot of files
simultaneously, where I need three or more `with` statements:
with open('foo') as foo:
On Tue, Aug 12, 2014 at 08:04:35AM -0500, Ian Cordasco wrote:
I think by introducing parentheses we are going to risk seriously
confusing users who may then try to write an assignment like
a = (open('spam') as spam, open('eggs') as eggs)
Seriously?
If they try it, they will get a syntax
On Sun, Aug 10, 2014 at 11:51:51AM -0400, Alexander Belopolsky wrote:
On Sat, Aug 9, 2014 at 8:44 PM, Steven D'Aprano st...@pearwood.info wrote:
It is certainly required when writing code that will behave the same in
version 2 and 3
This is not true. An alternative is to put
On Sat, Aug 09, 2014 at 02:44:10PM -0400, John Yeuk Hon Wong wrote:
Hi.
Referring to my discussion on [1] and then on #python this afternoon.
A little background would help people to understand where this was
coming from.
1. I write Python 2 code and have done zero Python-3 specific
On Fri, Aug 08, 2014 at 10:20:37PM -0400, Alexander Belopolsky wrote:
On Fri, Aug 8, 2014 at 8:56 PM, Ethan Furman et...@stoneleaf.us wrote:
I don't use sum at all, or at least very rarely, and it still irritates me.
You are not alone. When I see sum([a, b, c]), I think it is a + b + c,
On Mon, Aug 04, 2014 at 09:25:12AM -0700, Chris Barker wrote:
Good point -- I was trying to make the point about .join() vs + for strings
in an intro python class last year, and made the mistake of having the
students test the performance.
You need to concatenate a LOT of strings to see any
On Sat, Aug 02, 2014 at 10:52:07AM -0400, Alexander Belopolsky wrote:
On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano st...@pearwood.info wrote:
String concatenation with + is an attractive
nuisance for many people, including some who actually know better but
nevertheless do it. Also
On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote:
Python uses os.name, sys.platform, and various functions from `platform`
module to provide version info:
[...]
If Android is posixy enough (would `posix` module work on Android?)
then os.name could be left 'posix'.
Does anyone know
On Sun, Jul 13, 2014 at 05:13:20PM +0200, Andreas Maier wrote:
Second, if not by delegation to equality of its elements, how would the
equality of sequences defined otherwise?
Wow. I'm impressed by the amount of detailed effort you've put into
investigating this. (Too much detail to absorb,
On Tue, Jul 08, 2014 at 04:53:50PM +0900, Stephen J. Turnbull wrote:
Chris Angelico writes:
The reason NaN isn't equal to itself is because there are X bit
patterns representing NaN, but an infinite number of possible
non-numbers that could result from a calculation.
I understand
On Tue, Jul 08, 2014 at 04:58:33PM +0200, Anders J. Munch wrote:
For two NaNs computed differently to compare equal is no worse than 2+2
comparing equal to 1+3. You're comparing values, not their history.
a = -23
b = -42
if log(a) == log(b):
print a == b
--
Steven
On Tue, Jul 08, 2014 at 06:33:31PM +0100, MRAB wrote:
The log of a negative number is a complex number.
Only in complex arithmetic. In real arithmetic, the log of a negative
number isn't a number at all.
--
Steven
___
Python-Dev mailing list
On Tue, Jul 08, 2014 at 01:53:06AM +0200, Andreas Maier wrote:
Thanks to all who responded.
In absence of class-specific equality test methods, the default
implementations revert to use the identity (=address) of the object as a
basis for the test, in both Python 2 and Python 3.
Scrub out
On Tue, Jul 08, 2014 at 02:59:30AM +0100, Rob Cliffe wrote:
- *Every object has an identity, a type and a value.*
Hm, is that *really* true?
Yes. It's pretty much true by definition: objects are *defined* to have
an identity, type and value, even if that value is abstract rather than
On Sat, Jun 28, 2014 at 03:55:00PM -0400, Ben Hoyt wrote:
Re is_dir etc being properties rather than methods:
[...]
The problem with this is that properties look free, they look just
like attribute access, so you wouldn't normally handle exceptions when
accessing them. But .lstat() and
On Fri, Jun 27, 2014 at 03:07:46AM +0300, Paul Sokolovsky wrote:
With my MicroPython hat on, os.scandir() would make things only worse.
With current interface, one can either have inefficient implementation
(like CPython chose) or efficient implementation (like MicroPython
chose) - all
On Thu, Jun 26, 2014 at 09:37:50PM -0400, Ben Hoyt wrote:
I don't mind iterdir() and would take it :-), but I'll just say why I
chose the name scandir() -- though it wasn't my suggestion originally:
iterdir() sounds like just an iterator version of listdir(), kinda
like keys() and iterkeys()
On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote:
execfile() builtin function was removed in 3.0. This brings few
problems:
1. It hampers interactive mode - instead of short and easy to type
execfile(file.py) one needs to use exec(open(file.py).read()).
If the amount of
On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote:
On 6/7/2014 10:46 AM, Nick Coghlan wrote:
On 7 June 2014 04:50, Chris Withers ch...@simplistix.co.uk wrote:
Curious as to what lead to that implementation approach? What does it buy
that couldn't have been obtained by a mixin
On Fri, Jun 06, 2014 at 07:50:57PM +0100, Chris Withers wrote:
Hi All,
I've been trying to add support for explicit comparison of namedtuples
into testfixtures and hit a problem which lead me to read the source and
be sad.
Rather than the mixin and class assembly in the function I
On Fri, Jun 06, 2014 at 12:51:11PM +1200, Greg Ewing wrote:
Steven D'Aprano wrote:
(1) I asked if it would be okay for MicroPython to *optionally* use
nominally Unicode strings limited to ASCII. Pretty much the only
response to this as been Guido saying That would be a pretty lousy
option
On Wed, Jun 04, 2014 at 11:17:18AM +1000, Steven D'Aprano wrote:
There is a discussion over at MicroPython about the internal
representation of Unicode strings. Micropython is aimed at embedded
devices, and so minimizing memory use is important, possibly even
more important than performance
On Wed, Jun 04, 2014 at 01:14:04PM +, Steve Dower wrote:
I'm agree with Daniel. Directly indexing into text suggests an
attempted optimization that is likely to be incorrect for a set of
strings.
I'm afraid I don't understand this argument. The language semantics says
that a string is
On Wed, Jun 04, 2014 at 01:38:57PM +0300, Paul Sokolovsky wrote:
That's another reason why people don't like Unicode enforced upon them
Enforcing design and language decisions is the job of the programming
language. You might as well complain that Python forces C doubles as the
floating point
On Wed, Jun 04, 2014 at 03:32:25PM +, Steve Dower wrote:
Steven D'Aprano wrote:
The language semantics says that a string is an array of code points. Every
index relates to a single code point, no code point extends over two or more
indexes.
There's a 1:1 relationship between code
On Sun, Jun 01, 2014 at 06:11:39PM +1000, Steven D'Aprano wrote:
I think I know the answer to this, but I'm going to ask it anyway...
I know that there is a general policy of trying to write code in the
standard library that does not disadvantage other implementations. How
far does that go
There is a discussion over at MicroPython about the internal
representation of Unicode strings. Micropython is aimed at embedded
devices, and so minimizing memory use is important, possibly even
more important than performance.
(I'm not speaking on their behalf, just commenting as an
I think I know the answer to this, but I'm going to ask it anyway...
I know that there is a general policy of trying to write code in the
standard library that does not disadvantage other implementations. How
far does that go the other way? Should the standard library accept
slower code
On Sat, May 17, 2014 at 04:26:12AM -0400, Terry Reedy wrote:
On 5/17/2014 1:14 AM, Nick Coghlan wrote:
During a conversation today, I realised that the convention of
returning None from methods that change an object's state isn't
captured the Programming Recommendations section of PEP 8.
On Tue, Apr 29, 2014 at 07:48:00PM -0700, Jessica McKellar wrote:
Hi Adam,
Gentlemen,
Thanks for contributing to Python! But not everyone on this list is a guy.
And not all of the guys are gentlemen :-)
The term I sometimes use is gentlefolks, or even just folks. Ladies
and gentlemen
On Tue, Apr 29, 2014 at 12:07:00PM +0900, Stephen J. Turnbull wrote:
Mike Miller writes:
Microsoft's guidelines on where to install software are clear, and
don't make exceptions that tools should be installed to the root
of the drive to bypass file system permissions, for convenience.
On Sun, Apr 27, 2014 at 04:28:20PM -0400, Terry Reedy wrote:
On 4/27/2014 3:34 PM, Chris Barker wrote:
On Sun, Apr 27, 2014 at 9:40 AM, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Apr 26, 2014, at 12:33 AM, Janzert wrote:
So the one example under discussion
On Fri, Apr 25, 2014 at 08:13:35PM -0400, Donald Stufft wrote:
I agree that I’ve never taken the name to mean that you’re claiming any
sort of endorsement. There are a *vast* number of projects that implement
something that was defined somewhere else and I don’t think any reasonable
person
On Fri, Apr 25, 2014 at 08:42:02PM -0400, Donald Stufft wrote:
On Apr 25, 2014, at 7:20 PM, Ethan Furman et...@stoneleaf.us wrote:
On 04/25/2014 03:26 PM, Donald Stufft wrote:
pep8.py doesn’t violate PEP8, it just takes a stricter view of it.
If pep8 reports errors on things that
On Sat, Apr 26, 2014 at 01:59:27AM -0400, Fred Drake wrote:
On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano st...@pearwood.info wrote:
I think that a line beginning with #spam is ambiguous, it isn't clear
if it is intended as a comment spam or a key starting with #, so by
the Zen
On Fri, Apr 25, 2014 at 12:46:42PM -0400, Fred Drake wrote:
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin m...@the-compiler.org
wrote:
While it seems ConfigParser doesn't do any escaping as all, I'm
thinking it should at least raise some exception when such a value is
trying to be set.
On Thu, Apr 24, 2014 at 01:57:38PM +0100, Tim Golden wrote:
On 24/04/2014 12:59, Tal Einat wrote:
As far as I know that reason for these examples being frowned upon is
that they are needlessly redundant.
Oh, the irony! (Sorry, couldn't resist)
Not really ironic, since not all redundancy
On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote:
Does one ever use iteritems() et al without first invoking iter() on
it?
I can't speak for others, but I never invoke iteritems *with* iter().
What would be the point? iteritems is documented as returning an
On Sun, Apr 20, 2014 at 07:27:08PM +, Kristján Valur Jónsson wrote:
Well, for i in x and other iteration constructs already call iter
() on their iterable. That's the point. Unless you want to manually
iterate using next () then the distinction between an iterable and
an iterator is
On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote:
Wouldn't iterkeys simply be an alias for keys and so on?
I'm +1 on that.
No.
[steve@ando ~]$ python2.7 -c it = {}.iterkeys(); print it is iter(it)
True
[steve@ando ~]$ python3.3 -c it = {}.keys(); print(it is iter(it))
On Sat, Apr 19, 2014 at 10:38:39AM -0400, Nick Coghlan wrote:
On 19 Apr 2014 00:27, Steven D'Aprano st...@pearwood.info wrote:
On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote:
After spending some time talking to the folks at the PyCon Twisted
sprints, they persuaded me
On Fri, Apr 18, 2014 at 02:57:55PM -0700, Benjamin Peterson wrote:
On Fri, Apr 18, 2014, at 14:46, Jim J. Jewett wrote:
(1) I believe the recent consensus was that the number of comparisons
made in a dict lookup is an implementation detail. (Please correct me
if I am wrong.)
On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote:
After spending some time talking to the folks at the PyCon Twisted
sprints, they persuaded me that adding back the iterkeys/values/items
methods for mapping objects would be a nice way to eliminate a key
porting hassle for them (and
On Wed, Apr 09, 2014 at 02:40:21PM -0400, Geoffrey Spear wrote:
Of course, this raises the question of whether making slice assignment
not go into an infinite loop when the programmer asks it to is a
bugfix or a new feature.
Definitely a new feature.
Calling:
On Tue, Apr 08, 2014 at 06:49:13PM +0200, Antoine Pitrou wrote:
Le 08/04/2014 04:02, Steven D'Aprano a écrit :
Many, many more people take part in the CPython core developer culture
than just the core developers themselves. Look at the readership of this
mailing list, which is open
On Mon, Apr 07, 2014 at 03:04:18PM -0700, Benjamin Peterson wrote:
On Mon, Apr 7, 2014, at 14:58, Barry Warsaw wrote:
On Apr 07, 2014, at 05:47 PM, Alexander Belopolsky wrote:
Python used to have an alias for != and I for one miss in 3.x. I
don't think TOOWTDI should be the last word
On Mon, Apr 07, 2014 at 06:06:17PM -0700, Benjamin Peterson wrote:
On Mon, Apr 7, 2014, at 18:04, Steven D'Aprano wrote:
On Mon, Apr 07, 2014 at 03:04:18PM -0700, Benjamin Peterson wrote:
On Mon, Apr 7, 2014, at 14:58, Barry Warsaw wrote:
On Apr 07, 2014, at 05:47 PM, Alexander
There's a furious discussion going on at the python-list mailing list,
about negative timedelta strings:
py str(timedelta(0, -1))
'-1 day, 23:59:59'
This is documented. It's even documented as being somewhat unusual. I
found a tracker item for it, back in July 2010:
On Fri, Mar 28, 2014 at 09:20:35AM +, Kristján Valur Jónsson wrote:
I'll be willing to experiment with extending the heapq. methods to take an
optional map argument.
'map' would be a dict, mapping objects in the heap to indices. If provided,
each of the heapq methouds would
take care
On Wed, Mar 19, 2014 at 11:01:39PM +0100, Antoine Pitrou wrote:
On Thu, 20 Mar 2014 07:54:39 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Graeme Dumpleton has also subsequently written a library to handle easier
creation of correct proxy types: https://pypi.python.org/pypi/wrapt
(is
On Tue, Mar 18, 2014 at 05:05:56AM -0400, Terry Reedy wrote:
On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote:
Hi
I have a question about calling __eq__ in some cases.
We're thinking about doing an optimization where say:
if x in d:
return d[x]
if d.__contains__(x): return
On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote:
note that this is specifically about dicts, where __eq__ will be
called undecided number of times anyway (depending on collisions in
hash/buckets which is implementation specific to start with)
Exactly. Using a __eq__ method
On Tue, Mar 18, 2014 at 04:42:29PM -0700, Kevin Modzelewski wrote:
My 2 cents: it feels like a slippery slope to start guaranteeing the number
and ordering of calls to comparison functions -- for instance, doing that
for the sort() function would lock in the sort implementation.
Although I
On Thu, Mar 13, 2014 at 07:54:18AM +1100, Chris Angelico wrote:
On Thu, Mar 13, 2014 at 7:26 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I think you (or someone) first needs to find a BDFL delegate.
Traditionally, with syntax changes, there is a good chance that Guido
doesn't want to
On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote:
[...]
So can we please try to stop scheduling another major Python version
breaking almost all modules and all applications just to be pendantic?
No, we should not remove any old feature in Python 4. Python 4 should
be just a
On Wed, Mar 05, 2014 at 12:57:03PM -0800, Thomas Wouters wrote:
On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico ros...@gmail.com wrote:
+Had this facility existed early in Python's history, there would have been
+no need to create dict.get() and related methods;
FWIW, after
On Sat, Feb 22, 2014 at 01:15:13PM +1300, Greg Ewing wrote:
Eli Bendersky wrote:
For instance, it is sometime non-trivial to know which exceptions some
function may throw. When you write a try...raise statement, you think
hard about covering all the bases. In an expression you're unlikely
On Fri, Feb 21, 2014 at 04:42:36PM -0800, Ethan Furman wrote:
This is not just about better handling of [missing] default values, but of
better exception handling. This PEP adds the ability to use a scalpel
instead of a sledge hammer.
Beautifully said!
--
Steven
On Fri, Feb 21, 2014 at 02:04:45PM -0500, Yury Selivanov wrote:
Inconvenience of dict[] raising KeyError was solved by
introducing the dict.get() method. And I think that
dct.get('a', 'b')
is 1000 times better than
dct['a'] except KeyError: 'b'
I don't think it is better. I think that
On Sat, Feb 01, 2014 at 10:20:24PM +1000, Nick Coghlan wrote:
On 1 February 2014 16:04, Ethan Furman et...@stoneleaf.us wrote:
So we only fix bugs that don't work at all? By which I mean, if the
interpreter doesn't crash, we don't fix it?
No, we make a judgment call based on the severity
Hi all,
Over on the Python-ideas list, there's a thread about the new statistics
module, and as the author of that module, I'm looking for a bit of
guidance regarding backwards compatibility. Specifically two issues:
(1) With numeric code, what happens if the module become more[1]
accurate
On Fri, Jan 31, 2014 at 07:23:52PM -0800, Larry Hastings wrote:
Python is the language that cares about backwards-compatibility--bugs
and all. If your code runs on version X.Y, it should run without
modification on version X.(Y+Z) where Z is a positive integer.
Therefore it would be
On Mon, Jan 27, 2014 at 10:06:57PM -0800, Larry Hastings wrote:
If I were writing it, it might well come out like this:
[snip example]
+1 on this wording, with one minor caveat:
.. note: if times is specified using a keyword argument, and
provided with a negative value, repeat yields
On Mon, Jan 27, 2014 at 04:29:04AM -0800, Larry Hastings wrote:
The code currently has semantics that cannot be accurately represented
in a Python signature. We could do one of three things:
1) Do nothing, and don't allow inspect.Signature to produce a signature
for the function. This
On Sun, Jan 26, 2014 at 11:40:33PM -0500, Alexander Belopolsky wrote:
I would say no fix is needed for this doc because the signature suggests
(correctly) that passing times by keyword is not supported.
How do you determine that? Passing times by keyword works in Python 3.3:
py from itertools
On Sat, Jan 25, 2014 at 10:41:05AM +1000, Nick Coghlan wrote:
In this specific case, our general communication about the different
purposes of the core lists *isn't* particularly good,
Nick, I beg to differ: I think that our communication in this regard
actually is quite reasonable. Before
On Fri, Jan 24, 2014 at 08:07:43PM -0800, Larry Hastings wrote:
(Quick, because apparently nobody reads the long ones!)
In Python 3.3:
class C:
...def foo(self, a): pass
...
c = C()
help(c.foo)
shows you the signature foo(self, a).
That matches the
701 - 800 of 1505 matches
Mail list logo
