like an EnvironmentError to me, but I don't know that it should be a
ValueError or TypeError either.
--
Steven <[EMAIL PROTECTED]>
___
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/archive%40mail-archive.com
re i
is a natural number.
+0 on keeping unsubscriptable.
+1 on changing it to unidexable.
-1 on keeping the current misspelling.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
ht. It's a style thing.)
However, I'm happy for "no named lambdas" to be a guideline or
recommendation. I'm even happy for a stronger prohibition to apply
to the standard library. I don't dislike named lambdas, but I don't
expect others to like them.
--
Stev
t;>> dis.dis(lambda x: x+1)
Traceback (most recent call last):
TypeError: don't know how to disassemble code objects
It's quite annoying, I would have rather that they just removed the
module altogether. Better still would have been to disassemble code
objects to whatever byte
se my subjective opinion is that "iterdir" is an inelegant
and less than attractive name.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
with a
method call, the failure is silent and I keep getting the cached result.
Speaking of caching, is there a way to freshen the cached values?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
oking to change anything here, the current behaviour
is fine, I just want to ensure that an otherwise admirable doc
change does not get interpreted in the future in a way that
prevents classes from defining __eq__ to be non-reflexive.
--
Steven
___
ering
relations.
Unlike type and identity, "value" does not have a single concrete
definition, it depends on the class designer. In the case of object, the
value of an object instance is itself, i.e. its identity. I don't think
we need more than that.
--
Steven
_
eric value."
"The value of a float is the float's numeric value, or in the case of
INFs and NANs, that they are an INF or NAN."
"The value of a complex number is the ordered pair of its real and
imaginary components."
"The value of a re MatchObject is the Ma
disagree with their decision
(notably Bertrand Meyer of Eiffel fame, and our own Mark Dickenson), the
IEEE-754 committee led by William Kahan decided that the problems caused
by having NANs compare unequal to themselves were much less than the
problems that would have been caused without
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 ==
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 mail
a bug, it is a feature. As far as I am concerned,
this only needs documenting. If anyone needs list equality to honour the
special behaviour of NANs, write a subclass or an equal() function.
--
Steven
___
Python-Dev mailing list
Python-Dev
ix'.
Does anyone know what kivy does when running under Android?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
on.
As for prohibiting anything except numbers with sum(), that in my
opinion would be a bad idea. sum(vectors), sum(numeric_arrays),
sum(angles) etc. should all be allowed. The general sum() built-in
should accept any type that allows + (unless explicitly b
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
least
likely to understand why their code occasionally and unpredictably
becomes catastrophically slow, are far more likely to sum strings than
sum tuples or lists.
(I don't entirely agree with this rationale, I'd prefer a warning rather
than an exception.)
--
Steven
_
any specialist varieties. There are tack
hammers, claw hammers, framing hammers, lump hammers, rubber and wooden
mallets, "brass" non-sparking hammers, carpet hammers, brick hammers,
ball-peen and cross-peen hammers, and even more specialist versions like
y equivalent."
How does (s)he justify this claim?
"Explicit is better than implicit."
which is not logical. If you leave out `object`, that's implicit, not
explicit.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
rt of
writing your code, and reading it, in a dynamic manner is not justified.
Compare the natural way of writing this:
with open("spam") as spam, open("eggs", "w") as eggs, frobulate("cheese") as
cheese:
# do stuff with spam, eggs, cheese
versus the dyn
tor expressions and line continuations. I cannot
think of any examples where these multiple uses for parens has cause
meaningful confusion, and I don't think this one will either.
[1] Technically not, since it's the comma, not the ( ), which makes a
tuple, but a lot of people d
ript in the browser is effectively sandboxed, so I'm doubly
cautious about Python.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ommas, not the parentheses. E.g. this succeeds:
# Not a tuple, actually two context managers.
with open("/tmp/foo"), open("/tmp/bar", "w"):
pass
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
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:
> >
mful
that we have to forgo a useful piece of functionality to avoid it?
Some designs are bug-magnets, like the infamous "except A,B" syntax,
which fails silently, doing the wrong thing. Unless someone has a
convincing rationale for how and why this multi-line with will likewise
be a bu
PEP together, and I think it could
> help reduce some of the confusions around the expectations for Python
> 4.0 and the evolution of 3.x in general.
I think it's a good idea, so long as there's no implied or explicit
promise that Python language is now set in stone never to change
tion, you typically cannot include arbitrary
bytes in text files, and displaying them to the user is likewise
problematic. The usual solution is to support some form of
escaping, like \t #x0A; or %0D, to give a few examples.
--
Steven
___
h
os.listdir. Even in Python 3.1 it worked fine. I was able to list the
directory and open the file, so I'm not entirely sure where the problem
lies exactly. Can somebody demonstrate the failure mode?
--
Steven
___
Python-Dev mailing list
Python-De
developer blog:
> http://developerblog.redhat.com/2014/09/09/transition-to-multilingual-programming-python/
That's awesome! Thank you Nick.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
you ever say .{5} then it might match
> incorrectly.
I don't think the idea is to match on these smuggled bytes specifically.
I think the idea is to match *around* them. In the example above, we
might match everything from "Subject: " to the end of the line. So long
as we
hich is not the same
thing as a Unicode noncharacter.
> Characters are those code points that may be assigned
> an interpretation as a character, including undefined characters
> (private space and reserved).
So characters are code points which are characters, including undefined
characters? :-)
http://www.unicode.org/glossary/#character
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Python 2.x is
> installed by default than ``python`` should point to ``python2``. If
> Python 3.x is the default version and Python 2.x is the “optional”
> version than I think personally it makes sense to switch eventually.
> Maybe not immediately to give pe
icate Python 2 the way we did for Python 1? Then
> maybe Python 4 can reclaim /usr/bin/python.
I expect not quite. Perhaps 10 years though.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
;echo gotcha"
In other words, os.system is *already* an attack vector, unless you only
use it with trusted strings. I don't think the bash env vulnerability
adds to the attack surface.
Have I missed something?
--
Steven
___
Python-Dev m
. But
even better would be to look for a mailing list or forum for assembly
programming, machine code, or micro-code.
On Mon, Nov 03, 2014 at 09:19:46PM -0200, françai s wrote:
> I intend to write in lowest level of computer programming as a hobby.
[...]
--
Ste
what
other options are there apart from silently consuming the value?
Indeed that is exactly what the built-in zip does:
py> a = iter("abcdef")
py> b = iter("abc")
py> list(zip(a, b))
[('a', 'a'), ('b', 'b'), ('c&#
nd 3
in one code base: the use of `return value` in a generator.
In Python 2.x through 3.1, `return value` is a syntax error inside
generators. Currently, the only way to handle this case in 2+3 code is
by using `raise StopIteration(value)` but if that changes in 3.6 or 3.7
then ther
ons will behave like comprehensions in the face of
StopIteration). But trying to have both at the same time via a new
exception adds even more complexity and would leave everyone unhappy.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
*
contributions?
I know that there are people who think that mailing lists are old and
passe, and that we should shift discussion to a social media site like
Reddit. If we did, we'd probably get twenty times as many comments, and
the average quality would probably plummet. More is not nece
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
nore it, but that's kind of nasty and hackish
and shouldn't be considered good code.
Do you agree this is a reasonable way to look at it?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth
g to be used, I would expect to be able to re-use
pre-written module types. E.g. having written "module with properties"
(so to speak) once, I can just import it and use it in my next project.
--
Steven
___
Python-Dev mailing list
Python-Dev@pyth
g to my satisfaction that they have changed. (My
experience is that company culture rarely changes unless there is a
change in management, and even then only slowly.) Particularly given
GitHub's supposed egalitarian, non-hierarchical, and meritocratic
structure, that nobody apparently
they're cheaper and that's good for the poor."
Not that I'm comparing GitHub's actions with poisoning babies. What
GitHub did was much worse. *wink*
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
valid, but I am curious what
specific issues you have come across and wondering if there are things
which 3.5 can include to ease that transition. E.g. 3.3 re-added support
for u'' syntax.
--
Steven
___
Python-Dev mailing list
Python-D
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
;ve made my point. Whatever language you
are using in 5-10 years time, it will almost certainly be either mostly
static with some dynamic features like Java, or dynamic with optional
and gradual typing.
--
Steven
___
Python-Dev mailing list
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
x/Fraction, but not
times. The only difference is that instead of calling the type directly,
you call the appropriate classmethod.
What am I missing?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
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
1 - 100 of 1900 matches
Mail list logo
