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
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
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
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
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
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
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:
> [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
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
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
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
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
(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
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
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
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
_
16 matches
Mail list logo
