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 tra
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 iterke
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 .i
On Mon, Jul 07, 2014 at 04:52:17PM -0700, Ethan Furman wrote:
> On 07/07/2014 04:49 PM, Benjamin Peterson wrote:
> >
> >Probably the best argument for the behavior is that "x is y" should
> >imply "x == y", which preludes raising an exception. No such invariant
> >is desired for ordering, so defaul
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
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
c
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 unde
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
Python
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 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 Fri, Aug 01, 2014 at 10:57:38PM -0700, Allen Li wrote:
> On Fri, Aug 01, 2014 at 02:51:54PM -0700, Guido van Rossum wrote:
> > No. We just can't put all possible use cases in the docstring. :-)
> >
> >
> > On Fri, Aug 1, 2014 at 2:48 PM, Andrea Griffini wrote:
> >
> > help(sum) tells cle
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 wrote:
>
> > String concatenation with + is an attractive
> > nuisance for many people, including some who actually know better but
> > neverthele
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
On Fri, Aug 08, 2014 at 10:20:37PM -0400, Alexander Belopolsky wrote:
> On Fri, Aug 8, 2014 at 8:56 PM, Ethan Furman 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, but
> in Py
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 spec
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 wrote:
>
> > It is certainly required when writing code that will behave the same in
> > version 2 and 3
> >
>
> This is not true. An alter
On Tue, Aug 12, 2014 at 10:28:14AM +1000, Nick Coghlan wrote:
> On 12 Aug 2014 09:09, "Allen Li" 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 Thu, Aug 14, 2014 at 02:26:29AM +1000, Chris Angelico wrote:
> On Wed, Aug 13, 2014 at 11:11 PM, Isaac Morland 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 with a sandbox.
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, lim
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
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:
> >
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 22, 2014 at 04:42:29AM +0200, Oleg Broytman wrote:
> On Thu, Aug 21, 2014 at 05:30:14PM -0700, Chris Barker - NOAA Federal
> 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 file
> > with a pa
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 pa
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:
> http:
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
> 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 constants. T
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 Fri, Sep 19, 2014 at 04:44:26AM -0400, Donald Stufft wrote:
>
> > On Sep 19, 2014, at 3:31 AM, Bohuslav Kabrda 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" invoke w
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 suppor
On Fri, Sep 26, 2014 at 12:17:46AM +0200, Antoine Pitrou wrote:
> On Thu, 25 Sep 2014 13:00:16 -0700
> Bob Hanson 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/
> Fortunately
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 Sat, Nov 22, 2014 at 12:53:41AM +1100, Chris Angelico wrote:
> On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
> wrote:
> > Also, the proposal breaks a reasonably useful pattern of calling
> > next(subiterator) inside a generator and letting the generator terminate
> > when the data stream
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
> "cle
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
> over
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.
http://nedbatchelder.com/blo
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 wrote:
> > I'm sure that we'll get *more* contributions, but will they be *better*
> > contributions?
> >
> > I know that there are peopl
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 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 '
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 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 *conc
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
Pytho
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
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 etcet
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 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, *ar
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
> wrote:
>
> > Why can't int, str, list, tuple etc. be more like datetime?
>
>
> They are. In all these types, class methods call su
On Fri, Mar 06, 2015 at 09:37:05PM +0100, Antoine Pitrou wrote:
> On Fri, 06 Mar 2015 18:11:19 +
> Brett Cannon wrote:
> > And the dropping of docstrings does have an impact on
> > memory usage when you use Python at scale.
>
> What kind of "scale" are you talking about? Do you have any numbe
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 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 n
On Mon, Mar 09, 2015 at 09:52:01AM -0400, Neil Girdhar wrote:
> Here is a list of methods on
> int that should not be on IntFlags in my opinion (give or take a couple):
>
> __abs__, __add__, __delattr__, __divmod__, __float__, __floor__,
> __floordiv__, __index__, __lshift__, __mod__, __mul__, __
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 Wed, Mar 11, 2015 at 05:34:10PM +, Brett Cannon wrote:
> I have a poll going on G+ to see what people think of the various proposed
> file name formats at
> https://plus.google.com/u/0/+BrettCannon/posts/fZynLNwHWGm . Feel free to
> vote if you have an opinion.
G+ hates my browser and won'
On Tue, Apr 07, 2015 at 03:11:30AM +0100, Rob Cliffe wrote:
> As a matter of interest, how far away from mainstream am I in
> preferring, *in this particular example* (obviously it might be
> different for more complicated computation),
>
> def foo(x):
> return math.sqrt(x) if x >=
On Tue, Apr 07, 2015 at 08:47:25AM -0400, Ben Hoyt wrote:
> > My own preference would be:
> >
> > def foo(x):
> > if x >= 0:
> > return math.sqrt(x)
> > return None
>
> Kind of getting into the weeds here, but I would always invert this to
> "return errors early, an
On Tue, Apr 14, 2015 at 01:40:40PM -0400, Eric V. Smith wrote:
> But, I don't see a lot of keyword-only parameters being added to stdlib
> code. Is there some position we've taken on this? Barring someone saying
> "stdlib APIs shouldn't contain keyword-only params", I'm inclined to
> make numeric_
On Mon, Apr 20, 2015 at 11:34:51PM +0100, Harry Percival wrote:
> exactly. yay stub files! we all agree! everyone loves them!
Not even close.
--
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
On Mon, Apr 20, 2015 at 07:30:39PM +0100, Harry Percival wrote:
> Hi all,
>
> tldr; type hints in python source are scary. Would reserving them for stub
> files be better?
No no no, a thousand times no it would not!
Please excuse my extreme reaction, but over on the python-list mailing
list (co
On Mon, Apr 20, 2015 at 02:41:06PM -0400, Barry Warsaw wrote:
> On Apr 20, 2015, at 07:30 PM, Harry Percival wrote:
>
> >tldr; type hints in python source are scary. Would reserving them for stub
> >files be better?
>
> I think so. I think PEP 8 should require stub files for stdlib modules and
>
On Mon, Apr 20, 2015 at 08:37:28PM -0700, Guido van Rossum wrote:
> On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich wrote:
>
> > Twelve years ago a wise man said to me "I suggest that you also propose a
> > new name for the resulting language"
> >
>
> The barrage of FUD makes me feel like the wo
On Tue, Apr 21, 2015 at 11:56:15AM +0100, Rob Cliffe wrote:
> (Adding a type hint that restricted the argument to say a
> sequence of numbers turns out to be a mistake.
Let's find out how big a mistake it is with an test run.
py> def sorter(alist: List[int]) -> List[int]:
... return
On Tue, Apr 21, 2015 at 01:25:34PM +0100, Chris Withers wrote:
> Anyway, I've not posted much to python-dev in quite a while, but this is
> a topic that I would be kicking myself in 5-10 years time when I've had
> to move to Javascript or because everyone
> else has drifted away from Python as
On Tue, Apr 21, 2015 at 03:08:27PM +0200, Antoine Pitrou wrote:
> On Tue, 21 Apr 2015 22:47:23 +1000
> Steven D'Aprano wrote:
> >
> > Ironically, type hinting will *reduce* the need for intrusive,
> > anti-duck-testing explicit calls to isinstance() at runtime
On Tue, Apr 21, 2015 at 03:51:05PM +0100, Cory Benfield wrote:
> On 21 April 2015 at 15:31, Chris Angelico wrote:
> > Granted, there are some
> > vague areas - how many functions take a "file-like object", and are
> > they all the same? - but between MyPy types and the abstract base
> > types that
On Thu, Apr 23, 2015 at 03:25:30PM +0100, Harry Percival wrote:
> lol @ the fact that the type hints are breaking github's syntax highlighter
> :)
That just tells us that Github's syntax highlighter has been broken for
over five years. Function annotations go back to Python 3.0, more than
five y
On Thu, Apr 23, 2015 at 01:51:52PM -0400, Barry Warsaw wrote:
> Why "async def" and not "def async"?
>
> My concern is about existing tools that already know that "def" as the first
> non-whitespace on the line starts a function/method definition. Think of a
> regexp in an IDE that searches back
On Wed, Apr 22, 2015 at 11:26:14AM -0500, Ian Cordasco wrote:
> On a separate thread Cory provided an example of what the hints would look
> like for *part* of one function in the requests public functional API.
> While our API is outwardly simple, the values we accept in certain cases
> are actua
On Fri, Apr 24, 2015 at 03:44:45PM +0100, Cory Benfield wrote:
> On 24 April 2015 at 15:21, Steven D'Aprano wrote:
>
> > If the type hints are wrong, there are two errors: false positives, when
> > code which should be allowed is flagged as a type error; and false
> &g
On Fri, Apr 24, 2015 at 09:32:51AM -0400, Barry Warsaw wrote:
> On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote:
>
> >It seems to me that tools that search for r"^\s*def\s+spam\s*\(" are
>
> They would likely search for something like r"^\s*def\s+[a-z
On Sat, Apr 25, 2015 at 02:05:15AM +0100, Ronan Lamy wrote:
> * Hints have no run-time effect. The interpreter cannot assume that they
> are obeyed.
I know what you mean, but just for the record, annotations are runtime
inspectable, so people can (and probably have already started) to write
ru
On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote:
> # Syntactic sugar
> "Beautiful is better than ugly, " thus nice syntax is needed.
> Current syntax is very mechanical.
> Syntactic sugar is needed on top of current PEP.
I think the annotation syntax is beautiful. It reminds me of Pas
On Wed, Apr 29, 2015 at 06:12:37PM -0700, Guido van Rossum wrote:
> On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan wrote:
>
> > On 30 April 2015 at 10:21, Ethan Furman wrote:
> > > From the PEP:
> > >
> > >> Why not a __future__ import
> > >>
> > >> __future__ imports are inconvenient and easy to
On Wed, Apr 29, 2015 at 07:31:22PM -0700, Guido van Rossum wrote:
> Ah, but here's the other clever bit: it's only interpreted this way
> *inside* a function declared with 'async def'. Outside such functions,
> 'await' is not a keyword, so that grammar rule doesn't trigger. (Kind of
> similar to t
On Fri, May 01, 2015 at 09:24:47PM +0100, Arnaud Delobelle wrote:
> I'm not convinced that allowing an object to be both a normal and an
> async iterator is a good thing. It could be a recipe for confusion.
In what way?
I'm thinking that the only confusion would be if you wrote "async for"
ins
On Fri, Sep 08, 2017 at 10:37:12AM -0700, Nick Coghlan wrote:
> > def __eq__(self, other):
> > if other.__class__ is self.__class__:
> > return (self.name, self.unit_price, self.quantity_on_hand) ==
> > (other.name, other.unit_price, other.quantity_on_hand)
> > return NotIm
On Mon, Sep 11, 2017 at 07:39:07AM +1000, Chris Angelico wrote:
[...]
> As a language change, definitely not. But I like this idea for
> PYTHONBREAKPOINT. You set it to the name of a function, or to "pass"
> if you want nothing to be done. It's a special case that can't
> possibly conflict with no
On Wed, Oct 04, 2017 at 03:56:14PM -0700, VERY ANONYMOUS wrote:
> i want to learn
Start by learning to communicate in full sentences. You want to learn
what? Core development? Python? How to program? English?
This is not a mailing list for Python beginners. Try the "tutor" or
"python-list" mai
On Wed, Oct 25, 2017 at 04:32:39PM -0400, Alexander Belopolsky wrote:
> On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters wrote:
> > Why make parsing ISO time special?
>
> It's not the ISO format per se that is special, but parsing of str(x).
> For all numeric types, int, float, complex and even
> f
On Sun, Oct 29, 2017 at 12:31:01AM +0100, MRAB wrote:
> Not that I'm planning on making any further additions, just bug fixes
> and updates to follow the Unicode updates. I think I've crammed enough
> into it already. There's only so much you can do with the regex syntax
> with its handful of m
On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote:
> PEP: 563
> Title: Postponed Evaluation of Annotations
> This PEP proposes changing function annotations and variable annotations
> so that they are no longer evaluated at function definition time.
> Instead, they are preserved in ``_
On Mon, Nov 06, 2017 at 01:07:51PM +1000, Nick Coghlan wrote:
> That means our choices for 3.7 boil down to:
>
> * make this a language level guarantee that Python devs can reasonably rely on
> * deliberately perturb dict iteration in CPython the same way the
> default Go runtime does [1]
I agre
On Mon, Nov 06, 2017 at 12:27:54PM +0100, Antoine Pitrou wrote:
> The ordered-ness of dicts could instead become one of those stable
> CPython implementation details, such as the fact that resources are
> cleaned up timely by reference counting, that people nevertheless
> should not rely on if the
On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote:
> > I don't think that situation should change the decision,
>
> Indeed, it shouldn't. What may change it is the simple and obvious fact
> that there's no need to change anything, as proven by the 25-year
> history of the language.
On Mon, Nov 06, 2017 at 11:33:10AM -0800, Barry Warsaw wrote:
> If we did make the change, it’s possible we would need a way to
> explicit say that order is not preserved. That seems a little weird
> to me, but I suppose it could be useful.
Useful for what?
Given that we will hypothetically
On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote:
> I strongly opposed adding an ordered guarantee to regular dicts. If the
> implementation happens to keep that, great.
That's the worst of both worlds. The status quo is that unless we
deliberately perturb the dictionary order, develo
On Mon, Nov 06, 2017 at 06:35:48PM +0200, Paul Sokolovsky wrote:
> For MicroPython, it would lead to quite an overhead to make
> dictionary items be in insertion order. As I mentioned, MicroPython
> optimizes for very low bookkeeping memory overhead, so lookups are
> effectively O(n), but orderedn
On Mon, Nov 06, 2017 at 10:17:23PM -0200, Joao S. O. Bueno wrote:
> And also, forgot along the discussion, is the big disadvantage that
> other Python implementations would have a quite
> significant overhead on mandatory ordered dicts.
I don't think that is correct. Nick already did a survey, an
On Tue, Nov 07, 2017 at 05:28:24PM +1000, Nick Coghlan wrote:
> On 7 November 2017 at 16:21, Steven D'Aprano wrote:
> > On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote:
> >> Maybe OrderedDict can be
> >> rewritten to use the dict implement
On Tue, Nov 07, 2017 at 03:32:29PM +0100, Antoine Pitrou wrote:
[...]
> > "Insertion ordered until the first key removal" is the only guarantee
> > that's being proposed.
>
> Is it? It seems to me that many arguments being made are only relevant
> under the hypothesis that insertion is ordered e
On Tue, Nov 07, 2017 at 05:37:15PM +0200, Serhiy Storchaka wrote:
> 07.11.17 16:56, Steven D'Aprano пише:
> >To clarify: if we start with an empty dict, add keys A...D, delete B,
> >then add E...H, we could expect:
[...]
> Rather
>
> {A: 1, D: 4, C: 3} # move the
On Sun, Nov 19, 2017 at 08:24:00PM +, Mark Shannon wrote:
> Hi,
>
> Just one comment. Could the new behaviour of attribute lookup on a
> module be spelled out more explicitly please?
>
>
> I'm guessing it is now something like:
>
> `module.__getattribute__` is now equivalent to:
>
> def _
On Sun, Nov 19, 2017 at 05:34:35PM -0800, Guido van Rossum wrote:
> On Sun, Nov 19, 2017 at 4:57 PM, Steven D'Aprano
> wrote:
> > A minor point: this should(?) be written in terms of the public
> > interface for accessing namespaces, namely:
> >
> >
On Thu, Nov 30, 2017 at 11:54:39PM -0500, Random832 wrote:
> The OP isn't confusing anything; it's Eric who is confused. The quoted
> paragraph of the PEP clearly and unambiguously claims that the sequence
> is "arguments -> function -> call", meaning that something happens after
> the "function"
On Fri, Dec 01, 2017 at 08:24:05AM -0500, Random832 wrote:
> On Fri, Dec 1, 2017, at 05:31, Steven D'Aprano wrote:
> > I'm more confused than ever. You seem to be arguing that Python
> > functions CAN short-circuit their arguments and avoid evaluating them.
> > I
On Mon, Dec 18, 2017 at 06:11:05PM -0800, Chris Barker wrote:
> Now that dicts are order-preserving, maybe we should change prettyprint:
>
> In [7]: d = {'one':1, 'two':2, 'three':3}
>
> In [8]: print(d)
> {'one': 1, 'two': 2, 'three': 3}
>
> order preserved.
>
> In [9]: pprint.pprint(d)
> {'o
On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote:
> On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote:
> > On Dec 18, 2017, at 21:11, Chris Barker wrote:
> >
> >> Will changing pprint be considered a breaking change?
> >
> > Yes, definitely.
>
> Wait, what? Why would changing pp
On Mon, Dec 18, 2017 at 08:28:52PM -0800, Chris Barker wrote:
> On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano
> wrote:
>
> > > With arbitrary order, it made sense to sort, so as to always give the
> > same
> > > "pretty" representation.
What is the best practice for revisiting old enhancement requests on the
tracker, if I believe that the time is right to revisit a rejected issue
from many years ago? (Nearly a decade.)
Should I raise a new enhancement request and link back to the old one,
or re-open the original?
Thanks,
1 - 100 of 1539 matches
Mail list logo
