Yury Selivanov wrote:
> I propose to use the following syntax for assignment expressions:
>
> ( NAME = expr )
Yury, did you notice the subthread [1] that discusses the merits and
problems of the same idea (except for your point 3)?
[1] https://mail.python.org/pipermail/python-dev/2018-April/1
Tim Peters wrote:
> [Christoph Groth ]
> > I hope to have shown [1] that the same could be done for
> > assignments. A consistent value can be defined for any assignment
> > statement. So, all assignment statements could be redefined as
> > expressions and the language
Tim Peters wrote:
> [Christoph Groth ]
> > Still, it seems weird to have two different ways of binding names in
> > the language where one would be sufficient (i.e. the old one would
> > remain only for backwards compatibility). From the point of view of
> > someon
Tim Peters wrote:
> [Chris Angelico ]
> > I don't see much value in restricting the assignment target to names
> > only, but if that's what it takes, it can be restricted, at least
> > initially.
>
> I believe this point was made most clearly before by Terry Reedy, but
> it bears repeating :-) Thi
Ethan Furman wrote:
> On 04/20/2018 11:15 AM, Christoph Groth wrote:
> > Nick Coghlan wrote:
> >
> >> I also think that if "=" and ":=" both target the same kind of scope,
> >> there isn't enough new expressiveness introduced by the la
Nick Coghlan wrote:
> I also think that if "=" and ":=" both target the same kind of scope,
> there isn't enough new expressiveness introduced by the latter to
> justify the syntactic complexity of adding it.
OK, but then how about introducing assignment expressions with the "="
operator but *req
Chris Barker - NOAA Federal wrote:
> > Personally, I even slightly prefer
> >
> > a := 3
> >
> > to the commonplace
> >
> > a = 3
> > because it visually expresses the asymmetry of the operation.
>
> Careful here! That’s a fine argument for using := in a new language,
> but people using := when th
Steven Turnbull wrote:
Christoph Groth writes:
Wouldn't it be a pity not to liberate assignments from their boring
statement existence?
Maybe not. While it would be nice to solve the loop-and-a-half
"problem" and the loop variable initialization "problem" (not every
I'd like to break a lance for PEP 572.
I read that in the bad old days Python used to have a "=" operator in
expressions that had the meaning of today's "==". Perhaps there were
other reasons, but this choice alone meant that assignment (that was
using the same token) could not be made an express
Thanks, Victor, for the link to the bug fix! I suspected that the
original mechanism was something like that, but I believed that it
was so by design.
I find it a bit surprising that CPython gets changed between
versions in backwards-incompatible ways (even if it’s a bug fix)
without a notic
(I assume that this list is appropriate for this topic, but if it
isn't, I will be grateful for being redirected to the appropriate
place.)
It seems that warnings behave differently in Python 2 and Python
3. Consider the following script.
def func():
warnings.warn("Blabl
Steven D'Aprano wrote:
> On Tue, Feb 16, 2016 at 11:56:55AM -0800, Glenn Linderman wrote:
>> On 2/16/2016 1:48 AM, Christoph Groth wrote:
>> >Recent Python versions randomize the hashes of str, bytes and datetime
>> >objects. I suppose that the choice of these thr
Stephen J. Turnbull wrote:
> Glenn Linderman writes:
>
> > I think hashes of all types have been randomized, not _just_ the list
> > you mentioned.
>
> Yes. There's only one hash function used, which operates on byte
> streams IIRC. That function now has a random offset. The details of
> hash
Hello,
Recent Python versions randomize the hashes of str, bytes and
datetime objects. I suppose that the choice of these three types
is the result of a compromise. Has this been discussed somewhere
publicly?
I'm not a web programmer, but don't web applications also use
dictionaries that
Guido,
thanks for the quick reply! Of course I am aware that __xxx__ names are
special. But I was assuming that the features of a python interpreter
which are necessary to execute the pure python modules of the standard
library are supposed to be documented.
Christoph
_
Hi,
while playing with abstract base classes and looking at their
implementation, I've stumbled across the following issue. With Python
3.2, the script
class Foo(object):
__abstractmethods__ = ['boo']
class Bar(object):
pass
Bar.__abstractmethods__ = ['boo']
f = Foo()
b = Bar()
produces
16 matches
Mail list logo
