Frankly, multiple long meandering threads in s single mailing list are
not s very good archive either.
Ideally, the PEP is updated with a summary of the issues discussed as
the discussion unfolds.
(And links to the main discussion threads?)
It founds like that didn’t happen in this case, but
> I'd like to raise a potential edge case that might be a problem, and likely
> an increasingly common one: users with multiple installations of the *same*
> version of Python.
I would suggest that that use case is best addressed by a system that
isolates the entire python environment, such as
> On Feb 13, 2019, at 9:13 AM, Steve Dower
>
> I'm inclined to view "python" as the default, official command, with the
> versioned ones being workarounds added by distributors.
+1 — almost. I agree that “python” be the default, but it would be
good to require (or at least highly encourage)
> But as a rule,
>> there are a LOT of errors that can be pretty mysterious to newbies.
>
> Isn't that the very definition of "newbie"? That's half a joke, but I
> really don't think that programmers new to Python should be the
> standard.
Python is broadly advocated (and used) as a first
>. There's nothing mysterious about e.g. `TypeError: unsupported operand
type(s) for +: 'int' and 'str'`, unlike the case of the two concatenated
tuples. (Surely people get errors about int+str all the time, and they've
never complained -- unlike the tuple tuple case.)
Well, yes, that particular
If your primary concern is module clashes between plugins, maybe you
can hack around that:
1) if the plugins are providing copies of any other modules, then you
can simply require them to put them in their own namespace — that is,
a plug-in is a single package, with however many sub modules as it
I’m all for extending the life of 3.6, it sure feels recent to me!
> 3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several
> important syntax features it can be a minimal required version for long time.
Which is a good argument for why we may not need longer term support
> On the server side, the application could be doing something like
> assuming that the kwargs are e.g. column names
This is exactly a use-case for non-identifier strings in kwargs. The
rules for valid field names could very well be different than Python’s
rules.
The kwargs implementation is not
TL;DR-
+1 on advocating the term “generator comprehension” as a synonym for
“generator expression” in future documentation and instructional
materials.
The long version:
If we were starting from scratch, maybe it would makes sense to use “
builder” or something else, rather than comprehension.
Are we just having fun here?
Or might we actually start using a new naming convention for
the-syntax-formerly-known-as-generator-expressions?
-CHB
Sent from my iPhone
> On Jul 3, 2018, at 11:54 PM, Greg Ewing wrote:
>
> Steven D'Aprano wrote:
>> - list builder syntax is syntax which returns a
> On Jul 2, 2018, at 8:34 AM, Steven D'Aprano wrote:
Guido has decided — and despite my concerns, I’m going to enjoy my new
loop-and-a half construct:-)
But a comment on this:
> comprehension are no more special than
> assignments inside any other expression. They bind in the current scope,
>
> On Jun 28, 2018, at 8:21 PM, Tim Peters wrote:
Seems it’s all been said, and Tim’s latest response made an excellent
case for consistency.
But:
> Regardless of how assignment expressions work in listcomps and genexps, this
> example (which uses neither) _will_ rebind the containing block's
Sent from my iPhone
> > So what about:
> >
> > l = [x:=i for i in range(3)]
> >
> > vs
> >
> > g = (x:=i for i in range(3))
> >
> > Is there any way to keep these consistent if the "x" is in the regular
> > local scope?
>
> I'm not clear on what the question is. The list comprehension would
> We shouldn't be uniquely or especially concerned just because
> Microsoft has purchased Github. Nothing has changed.
Exactly — but this change HAS made people think about an issue that we
should have already been thinking about.
At the end of the day, anyone, or any project, would be well
>
> This may even be a bug/feature of IPython,
Ahh, thanks! I’ll look into that.
-CHB
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
> between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it
>> easier to write py2/py3 compatible code.
>> u"string", b'bytes %i' % something -- and when where the various
>> __future__ imports made available?
>>
>
> You'll need to be more specific. __future__ has been around for
> while the changes introduced by Python 3
> affect pretty much everyone, even people who only write small simple
> scripts.
Sure they do, but the *hard stuff* not so much.
I have found 2to3 conversion to be remarkably easy and painless.
And the whole Unicode thing is much easier.
CHB
>
Inspired by chg:
Could one make a little startup utility that, when invoked the first
time, starts up a raw python interpreter, keeps it running somewhere,
and then forks it to run the actual python code.
Then every invocation after that would make a new fork. I presume
forking is a LOT faster
18 matches
Mail list logo
