m at runtime. Was it *performance-critical* code? I don't
know, that was the point of my earlier rambling -- I could demonstrate a
speedup of the individual functions in benchmarks, but nobody spent the
effort to determine which functions were performance critical.
--
Steven
_
u
remember when you couldn't exchange text files from Macintosh to Windows
and visa versa without data being corrupted. Now, so long as both sides
use Unicode, data corruption ought to be a thing of the past.
It's not, but only because some operating systems still insist on using
no
ll documented in the PEPs
themselves, for somebody who is willing to do a bit of reading.
Could the process be more clear? Could the existing docs be improved? Of
course the answers to these questions are Yes, nothing is perfect. But
overall, I found the PEP
f eggs."""
eggs = None
print(spam.__doc__)
=> 'Amount of eggs.'
> Metaclass "ObjectSpec" would extend ABCMeta to search class source code for
> comments before members assignement,
What do you expect to happen when the source code is not available?
ise TypeError("Expected int but got '{}'".format(obj.__class__.__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
On Mon, Dec 16, 2013 at 07:30:56AM +1000, Nick Coghlan wrote:
> On 16 Dec 2013 02:58, "Ethan Furman" wrote:
> >
> > On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
> >>
> >> On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
> >&
that they use in their day job is subject to exactly the same outside
pressures as everyone else ("RedHat ships with Python 2.6, so that's the
version we're using").
--
Steven
___
Python-Dev mailing list
Python-Dev@python.
7;s
not quite as straightforward as "done". If it were, we wouldn't need
text strings :-)
--
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
: 'utf-8' codec can't decode byte 0xff in position 0:
invalid start byte
I wouldn't want it to guess the encoding by default. See the Zen about
ambiguity.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://
ally poor choice, since there
are many incompatible Cyrillic code-pages. On the other hand, it's also
an especially good example of how you need to know the encoding before
you can make sense of the data.
Again, note that if you know the encoding you are intending to use is
not La
it. Python 3 did
not cause encoding issues, and in these days of code being interchanged
all over the world, any programmer who doesn't have at least a basic
understanding of this is like a programmer who doesn't understand why
" cannot multiply correctly":
py> 0.7*7 == 4.9
on 3.3 and above, it can be written as:
u'%.1f %.1f %.1f RG' % (r, g, b)
which conveniently is exactly the same syntax you would use in Python 2.
That's *much* nicer than your suggestion:
> is more confusing than:
>
> b'%s %s %s RG' % tuple(map(lambda x: (u'%.1f' % x).encode('ascii'),
> (r, g, b)))
--
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 Sat, Jan 11, 2014 at 01:56:56PM +0100, Juraj Sukop wrote:
> On Sat, Jan 11, 2014 at 6:36 AM, Steven D'Aprano wrote:
> > If you consider PDF as binary with occasional pieces of ASCII text, then
> > working with bytes makes sense. But I wonder whether it might be better
&g
On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
> On 01/11/2014 07:38 AM, Steven D'Aprano wrote:
> >
> >The point that I am making is that many people want to add formatting
> >operations to bytes so they can put ASCII strings inside bytes. But (as
> &
t string methods from Python 2,
> so it doesn't hurt adding some more of the missing features
> from Python 2 on top to make life easier for people dealing
> with multiple/unknown encoding data.
I personally think it was a mistake to keep text operations like upper()
and lower() on byt
do you use the
Python 2 string type to make processing Unicode text easier?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyth
line endings in text mode.
So I did! Thank you for the correction.
--
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
tin-1, so everything is a
subset of Unicode, namely U+ to U+00FF. That means there are no
astral characters, and no behavioural differences between wide and
narrow builds (apart from memory use).
--
Steven
___
Python-Dev mailing list
Python-De
whatever technique is necessary. Here's one way to get a
blob of binary data:
# encode four C shorts into a fixed-width struct
struct.pack(">", 23, 42, 17, 99)
Here's another way:
# encode a text string into UTF-16
"My name is Steven".encode("utf-16be"
On Sat, Jan 11, 2014 at 11:05:36AM -0800, Ethan Furman wrote:
> On 01/11/2014 10:36 AM, Steven D'Aprano wrote:
> >On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
> >>
> >> unicode to bytes
> >> bytes to unicode using latin1
> >&g
On Sun, Jan 12, 2014 at 12:52:18PM +0100, Juraj Sukop wrote:
> On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano wrote:
>
> > On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote:
> >
> > > AFAIK (and just for the record), there could be both Latin1 te
ant to do after assembling the
whole string, but before calling encode.
Even if you intend to encode to bytes at the end, you might prefer to
work in the text domain right until just before the end:
- no need for b' prefixes;
- indexing a string returns a 1-char string, not an int;
- can use t
On Mon, Jan 13, 2014 at 07:31:16AM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > then the name is horribly misleading, and it is best handled like this:
> >
> > content = '\n'.join([
> >
0, Ethan Furman wrote:
> On 01/11/2014 06:29 PM, Steven D'Aprano wrote:
[...]
> Since you're talking to me, it would be nice if you addressed the same
> use-case I was addressing, which is mixed: ascii-encoded text,
> ascii-encoded numbers, ascii-encoded bools, binary-encoded
On Mon, Jan 13, 2014 at 01:03:15PM +1100, Steven D'Aprano wrote:
> code speaks louder than words: http://www.pearwood.info/ethan_demo.py
[...]
Ethan refers to code like:
template % ("срЃ".encode('cp1251').decode('latin-1'), 42,
blob.decode('latin-1&#
based on statistics. If the library adjusts a frequency
table, does that reflect a bug or an enhancement or both?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https:
".
>
> --David
>
> PS: I've always thought of "wire format" as *including* files...a file is
> a just a "wire" with an indefinite destination and transmission time
Nice analogy! I must steal it :-)
--
Steven
___
ery
single post in its entirety, I thought I understand the purpose of
asciistr was exactly that, to produce something that was compatible with
both bytes and strings.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
nd strings makes good semantic sense. If
this discussion has taught me anything, it is that mixing the two is
"Here Be Dragons" territory, fraught with danger.
It may be that there are applications where mixing them is
*unavoidable*, but I think that it's never *sensible*.
-
d expect
> a method called __bytes__ on an int to return some
> version of its binary value.
+1
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
y bit of duplicated
code, but less than a dozens lines including a docstring.
Given how easy it usually is to write 2/3 compatible code, I don't think
that limiting myself to a subset that works unchanged in both would be
useful to me. That would be a step backward, like goi
On Wed, Jan 15, 2014 at 10:34:48PM +, Mark Lawrence wrote:
> On 15/01/2014 22:22, Brett Cannon wrote:
> >
> >
> >
> >On Wed, Jan 15, 2014 at 5:00 PM, Steven D'Aprano ><mailto:st...@pearwood.info>> wrote:
> >
> >On Thu, Jan 16, 20
On Wed, Jan 15, 2014 at 05:46:07PM -0800, Glenn Linderman wrote:
> On 1/15/2014 4:03 PM, Steven D'Aprano wrote:
> >What precisely does it do? If it's so obvious, why is this thread so
> >long?
>
> It produces a formatted representation of the object in bytes. For
e
> hard-to-diagnose corruption.
An example: if you have the byte b'\x63', calling upper() on that will
return b'\x43'. That is only meaningful if the byte is intended as the
ASCII character "c".
> Footnotes:
&g
or float depending on the format code; so the above example
> would have bytes.__format__ calling int() on myNum(17),
The above example you give doesn't have any bytes in it. Can you explain
what you meant to say? I'm guessing you intended this:
b'the value is: %d'
. Would a feature
request "Allow None as default protocolname" be accepted?
--
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
) are not
> supported.
+1 on not supporting b'%r' (i.e. I agree with the PEP).
Why not support b'%a'? That seems to be a strange thing to prohibit.
Everythng else, well done and thank you.
--
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 Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote:
> On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
> >>Numeric Format Codes
> >>
> >>
> >>To properly handle int and float subclasses, int(), index(), and float()
> >
sm in an otherwise
content-less post was out of proportion to the magnitude of Ram's
transgression.
--
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
s a mistake...)
> A) pydoc and help() should not show bound parameters in the signature,
> like inspect.signature.
> B) pydoc and help() should show bound parameters in the signature, like
> inspect.getfullargspec.
Provided they are described as *methods* rather than *functions*, bound
> OverflowError: long int too large to convert to int
I don't think it does. I think it suggests that something is trying to
convert an unsigned value into an int, and failing. I note that repeat
is happy to work with negatives times one at a time:
py> it = repeat('a', time
of repeat so that:
repeat(x, -1)
and
repeat(x, times=-1)
behave the same. Is that actually what you mean, or have I
misunderstood?
Are there any other functions in the standard library where the
behaviour differs depending on whether an argument is given positionally
or by keyword?
ative value, repeat yields the object forever.
>This is a bug, its use is unsupported, and this behavior may be
>removed in a future version of Python.
How about changing "may be removed" to "will be removed", he asks
hopefully? :-)
--
Steven
_
Repeat 100 times, or forever.
repeat(x, times=random.choice(values))
I can see that delaying for a depreciation cycle is the responsible
thing to do. I don't think delaying fixing this until some hypothetical
distant Python 4000 is a good idea.
--
Steven
__
e) in 3.5
>
> * deprecate the problematic behaviour in 3.5 and then start treating
> it as equivalent to the positional argument handling in 3.6+
Seems reasonable to me.
Thanks again for the nice summary.
--
Steven
___
Python-Dev mailing list
wards compatibility under circumstances which are not part of the
intended API, but just work by accident?
[1] Or, for the sake of the argument, less accurate.
[2] And sets.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.py
int(arg) except ValueError: abort("Invalid int")
)
Actually, not quite so nice as I first thought, since you're relying on
the side-effects of abort() rather than returning a value. But apart
from that quibble, the ability to guard *small* subcalculati
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!
-
pression, without giving up the useful property that the
"except" clause is only evaluated when needed, not in advance.
(Chris, I think that ought to go in the motivation section of the PEP.)
--
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
"Sure, you can catch the KeyError yourself, but 'get' is a fundamental
operation for mappings, and I think that dict should implement a 'get'
method just to be complete."
Or perhaps not. Some developers prefer minimalist APIs, some developers
prefer more exhausti
Perhaps we need a long-term schedule?
3.5: August 2015
3.6: February 2017
3.7: August 2018
3.8: February 2020
3.9: August 2021
4.0: February 2023
give or take a few months.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mai
wait
until after the summit before declaring it categorically rejected,
perhaps somebody will persuade Guido to change his mind :-)
But either way, thanks for tackling this, the threads about syntax were
monsterous and I ran out of steam trying to keep up with it all long
ago.
--
Steven
__
an __eq__ with side-effects is legal Python and may in
fact be useful.
It's a tricky one... I don't know how I feel about short-cutting normal
Python semantics for speed. On the one hand, faster is good. But on the
other hand, it makes it harder to reason about code when things go
do_that()
do_something_else()
spam = d[x]
Assuming no modifications to d, will the second lookup still be
optimized?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsub
prised if __hash__
isn't called twice). But I worry that I have missed something.
--
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
the binary operator type dispatch).
>
> Oh indeed, you're right. I think my proposal is taking water.
Nevertheless, I would like to see a standard way to proxy dunder
methods.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https
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:
http://bugs.python.org/
gt; def pop(i):
>return heapq.heappop(heap, map)
>
> def remove(i):
> heapq.heapdel(heap, map[i], map)
If you're going to make heapq more complex, wouldn't it be better to
encapsulate the logic into a Heap class? heapq should remain the same,
and Heap could (if acc
that "import this" has become
less of an Easter Egg and more of a standard Python module :-)
--
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 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 A
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
>
t to
indicate that it was infinitely long, and list could raise an exception
*before* consuming all available memory.
http://legacy.python.org/dev/peps/pep-0424/
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
t; > if I am wrong.)
>
> Absolutely.
>
> >
> > (2) Is "the item will be hashed at least once" a language guarantee?
>
> No. (Would that be useful at all?)
I'm curious under what circumstances a key won't be hashed at all.
--
Steven
__
ing to Python 3 for affected Python 2 users.
To me, this feels more like re-adding cruft for trivial benefit. I would
want to see justification for why this gives *significant* benefit
before I could support it. As the PEP stands now, I'm -1. I might be
persuaded to change to 0 if the dict
the Twisted folks (or Nick, if he wants to speak for
them) have to justify why it's significant.
--
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 Sat, Apr 19, 2014 at 10:38:39AM -0400, Nick Coghlan wrote:
> On 19 Apr 2014 00:27, "Steven D'Aprano" 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 Twiste
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
interato
e Nick's suggestion sound better by
suggesting an even worse alternative, it's working :-)
--
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
son of this, as far as I am concerned, is "Don't transmit source
code through noisy channels that delete parts of your code.")
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
ning with comment_prefixes? The
specification doesn't say, but nor does it say that it's undefined
behaviour.
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,
, or make them more or less strict, is
okay, but I would expect that by default it should check for PEP 8
compliance, exactly PEP 8 compliance, and nothing but PEP 8 compliance.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https:/
ess that they're only errors if the checker is running in PEP 8
compatibility mode, where it is supposed to check for PEP 8 compliance.
That's the crux of Nick's, and Ethan's, argument: with a name like
"PEP8", it is reasonable to expect that by default the checker
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 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 sta
mple.
If the only example given was one-arg-per-line, then the reader might
wrongly assume that *only* one arg was allowed. But since the example
shows more than one arg per line (two in the above example), I expect
that people will read it as "some arbitrary number" rather than &
that the mere fact that Microsoft disapproves of
installing applications into the root should be good enough reason to
not do it. In the absense of an extremely compelling reason not to do
so, we should be a "good citizen" regardless of the OS.
--
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
even just "folks". "Ladies
and gentlemen" is just too old-fashioned and formal. "Folks" is nicely
informal and all-inclusive, regardless of sex or class we're all just
folks.
--
Steven
___
Python-Dev mailing l
s. Ruby prefers methods that return self and are
therefore chainable, while Python built-ins do not.
I think it would be worth having PEP 8 make it clear that:
- built-ins, and types which share the same interface as built-ins,
should have mutators which return None rather than self;
- but thir
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 because
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 implementa
operations are a quality of
implementation issue, not a deal breaker to call it a Python. I can't
see any requirement in the docs that str[n] must take O(1) time, but
perhaps I have missed something.
--
Steven
___
Python-Dev mailing list
P
ver decision, by the
way) so I look forward to seeing how their internal-utf8 implementation
stacks up against CPython's FSR implementation.
Out of curiosity, when the FSR was proposed, did anyone consider an
internal UTF-8 representation? If so, why was it rejected?
--
Steven
_
de
> encoding support, because it's highly bloated, but let people use any
> encoding they like. That comes at some price, like length of strings in
> characters are not know to runtime, only in bytes
What's does uPy return for the length of '∞'? If the answer is
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.
> > Th
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
> mo
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 &qu
on ActiveState by Raymond Hettinger.
Start here:
http://code.activestate.com/recipes/500261-named-tuples/?in=user-178123
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
nd inject it
into the new class. As far as I can see, it's only __new__ that benefits
from the exec approach.
Anyone tried this yet? Is it worth an experiment?
--
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
Microsystems Inc.)] on java1.6.0_27
Type "help", "copyright", "credits" or "license" for more information.
>>> import java
>>>
So you could do this:
from upy import execfile
execfile("file.py")
So long as you
On Wed, Jun 27, 2018 at 09:52:43PM -0700, Chris Barker wrote:
> It seems everyone agrees that scoping rules should be the same for
> generator expressions and comprehensions,
Yes. I dislike saying "comprehensions and generator expressions" over
and over again, so I just say "comprehensions".
P
On Sat, Jun 30, 2018 at 06:30:56PM +1000, Nick Coghlan wrote:
> The significant semantic differences between "{x : 1}" and "{x := 1}"
> are also rather surprising :)
*Significant* and obvious differences are good. It's the subtle
differences that you don't notice immediately that really hurt:
On Thu, Jun 28, 2018 at 03:42:49PM -0700, Chris Barker via Python-Dev wrote:
> If we think hardly anyone is ever going to do that -- then I guess it
> doesn't matter how it's handled.
That's how you get a language with surprising special cases, gotchas and
landmines in its behaviour. (Cough PHP
On Sat, Jun 30, 2018 at 11:32:03PM -0500, Tim Peters wrote:
[...]
> So, no, gaining performance is _not_ the motivation here. You already had
> a way to make it "run fast'. The motivation is the _brevity_ assignment
> expressions allow while _retaining_ all of the two-statement form's
> advantag
On Sun, Jul 01, 2018 at 08:35:08AM -0700, Michael Selik wrote:
> On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote:
>
> > So, ya, when someone claims [assignment expressions will] make Python
> > significantly harder to teach, I'm skeptical of that claim.
> >
>
> I don't believe anyone is making
On Wed, Jun 27, 2018 at 03:31:42PM -0700, Guido van Rossum wrote:
> I'd also like to keep the rule prohibiting use of the same name as a
> comprehension loop control variable and as an inline assignment target;
> this rule would also prohibit shenanigans with nested comprehensions (for
> any set o
On Wed, Jun 27, 2018 at 07:29:52PM -0500, Tim Peters wrote:
[...]
> For example, if the name is declared "global" in the outer scope, you'll
> get a compile-time error if you try to declare it "nonlocal" in the
> contained scope. "parentlocal" adjusts its meaning accordingly, becoming a
> synonym
On Wed, Jul 04, 2018 at 11:13:20AM +1200, Greg Ewing wrote:
> Terry Reedy wrote:
> >If we had followed the math precedent, instead of >language>, we would have set builders, list builders, dict builders, and
> >generator builders.
>
> I was intending to suggest something like that back when
> co
On Tue, Jul 03, 2018 at 09:54:22PM -0400, Terry Reedy wrote:
> > results = [(x, y, x/y) for x in input_data for y in [f(x)] if y > 0]
>
> Would (f(x),) be faster?
There is a deferred feature request to optimize "for x in [item]" as
equivalent to "for x in (item,)", to avoid constructing a
On Wed, Jul 04, 2018 at 03:21:29PM +0400, Abdur-Rahmaan Janhangeer wrote:
> was going to tell
>
> instead of := maybe => better
>
> := too close to other langs
The fact that := will be familiar to many people (especially if they
know Go, Pascal or Eiffel etc) is a point in its favour.
https://
On Tue, Jul 03, 2018 at 03:24:09PM -0700, Chris Barker via Python-Dev wrote:
> Over the years I've been using it (most of its life), Python has evolved to
> become much less of a "scripting" language, and much more of a "systems"
> language, and this addition is a (pretty significant) step more in
On Wed, Jul 04, 2018 at 01:03:02AM -0700, Devin Jeanpierre wrote:
> The PEP doesn't talk about it, but FWIW, Go and C++17 if statements
> allow you to put arbitrary simple statements in the suite header, and
> by doing that, solves all the issues you and the PEP mentioned.
Whether they solve "all
301 - 400 of 1900 matches
Mail list logo
