On 29 November 2017 at 16:13, David Mertz wrote:
> Strong -1 still from me. Too special case for syntax. Just write a function
> 'first_non_none()' that can perfectly will handle the need.
That's the equivalent of SQL's COALESCE, and it's insufficient for the
same reason "and" and "or" are syntax
2017-11-29 11:14 GMT+03:00 Nick Coghlan :
> It's OK to say "the use case exists, but I still
> don't want that particular syntax for it in Python" (I'm personally
> inclined to agree with you on that front). It's not OK to try to claim
> there are no use cases where the status quo is awkward enou
In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
already was deprecated when the plistlib module was added to the regular
stdlib in Python 2.6.
This is a dict subclass which allows to access items as attributes.
d = plistlib.Dict()
d['a'] = 1
assert d.a == 1
d.b = 2
asser
On 29 November 2017 at 18:49, Kirill Balunov wrote:
> 2017-11-29 11:14 GMT+03:00 Nick Coghlan :
>>
>> It's OK to say "the use case exists, but I still
>> don't want that particular syntax for it in Python" (I'm personally
>> inclined to agree with you on that front). It's not OK to try to claim
>>
On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote:
> 29.11.17 08:08, Steven D'Aprano пише:
> >Perl is hardly the only language with null-coalescing operators -- we
> >might better describe ?? as being familiar to C#, PHP, Swift and Dart.
> >That's two mature, well-known languages and
בתאריך יום ד׳, 29 בנוב׳ 2017, 11:46, מאת Steven D'Aprano <
[email protected]>:
> On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote:
> > 29.11.17 08:08, Steven D'Aprano пише:
> > >Perl is hardly the only language with null-coalescing operators -- we
> > >might better describe ?? a
Kirill Balunov writes:
> Since the proposed semantics is more similar to the idea of "or", may be it
> is better to consider something like:
>
> timeout then local_timeout then global_timeout
>
> I do not know how much this is a frequent case to be worthy of a keyword.
That sounds awkward... wha
בתאריך יום ד׳, 29 בנוב׳ 2017, 12:29, מאת Lele Gaifax :
> Kirill Balunov writes:
>
> > Since the proposed semantics is more similar to the idea of "or", may be
> it
> > is better to consider something like:
> >
> > timeout then local_timeout then global_timeout
> >
> > I do not know how much this
On Wed, 29 Nov 2017 09:39:57 +0200
Serhiy Storchaka
wrote:
> 29.11.17 03:34, Steven D'Aprano пише:
> > This wastes the opportunity to fail fast on operations which cannot
> > possibly succeed, e.g. list(count()) must eventually fail with
> > MemoryError. Or worse: if the OS starts thrashing trying
On Wed, Nov 29, 2017 at 5:46 AM, Alon Snir wrote:
> I would like to mention that the issue of assignment to a target list, is
> also relevant to the case of elementwise assignment to a mutable sequence
> (e.g. lists and arrays). Here as well, the rhs of the assignment statement
> states the num
29.11.17 11:45, Steven D'Aprano пише:
On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote:
29.11.17 08:08, Steven D'Aprano пише:
Perl is hardly the only language with null-coalescing operators -- we
might better describe ?? as being familiar to C#, PHP, Swift and Dart.
That's two m
On 28/11/17 23:15, Alon Snir wrote:
On Wed, Nov 29, 2017 at 5:46 AM, Alon Snir wrote:
I would like to mention that the issue of assignment to a target list, is also
relevant to the case of elementwise assignment to a mutable sequence (e.g.
lists and arrays). Here as well, the rhs of the assig
What about more English-like syntax:
X or else Y
E.g.
cache.get(foo) or else expensive_call(foo)
Stephan
Op 29 nov. 2017 12:54 schreef "Serhiy Storchaka" :
29.11.17 11:45, Steven D'Aprano пише:
On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote:
>
>> 29.11.17 08:08, Steven D'A
On 29 November 2017 at 21:53, Serhiy Storchaka wrote:
> 29.11.17 11:45, Steven D'Aprano пише:
>> On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote:
>>> What is the syntax of the ternary operator in these languages?
>>
>> All four use:
>>
>> condition ? first : second
>>
>> for
On 29 November 2017 at 22:38, Stephan Houben wrote:
> What about more English-like syntax:
>
> X or else Y
The problem with constructs like this is that they look like they
should mean the same thing as "X or Y".
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
What about a more general:
A if B else C
which would allow
A if is not None else C
but also e.g.
A if >= 1 else 0
Stephan
Op 29 nov. 2017 13:41 schreef "Nick Coghlan" :
> On 29 November 2017 at 22:38, Stephan Houben wrote:
> > What about more English-like syntax:
> >
> > X or else Y
>
> T
29.11.17 14:39, Nick Coghlan пише:
"a if def else b" -> pronounced "a if defined, else b"
I understand "a if defined, else b" as
try:
result = a
except (NameError, AttributeError, LookupError):
result = b
The problem is that None is not undefined. This is a regula
On 29 November 2017 at 12:41, Nick Coghlan wrote:
> On 29 November 2017 at 22:38, Stephan Houben wrote:
>> What about more English-like syntax:
>>
>> X or else Y
>
> The problem with constructs like this is that they look like they
> should mean the same thing as "X or Y".
Keyword based and mult
29.11.17 15:01, Stephan Houben пише:
What about a more general:
A if B else C
which would allow
A if is not None else C
but also e.g.
A if >= 1 else 0
This look the most "natural" to me. I.e. the least "unnatural". If we
even will introduce a new special syntax I will prefer this syntax.
As reference of prior art, there is https://pypi.python.org/pypi/munch in
PyPI
On 29 November 2017 at 05:52, Serhiy Storchaka wrote:
> In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
> already was deprecated when the plistlib module was added to the regular
> stdlib in Pyt
On Wed, Nov 29, 2017 at 3:12 PM Serhiy Storchaka
wrote:
> 29.11.17 15:01, Stephan Houben пише:
> > What about a more general:
> >
> > A if B else C
> >
> > which would allow
> >
> > A if is not None else C
> >
> > but also e.g.
> >
> > A if >= 1 else 0
>
> This look the most "natural" to me. I.e
I didn't say no use case exists, but rather "too special case." And/or
shortcutting is great, but truthiness feels much more general than noneness
to me.
But yes, 'first_non_none()" might have to address laziness in some manner,
depending on the use case. Zero argument lambdas and expression quoti
On Mon, Nov 27, 2017 at 3:49 PM, Greg Ewing
wrote:
> C Anthony Risinger wrote:
>
>> * Perhaps existence of `__len__` should influence unpacking? There is a
>> semantic difference (and typically a visual one too) between 1-to-1
>> matching a fixed-width sequence/container on the RHS to identifiers
Hi,
As mentioned, using logging everywhere has some advantages. It doesn't have to
be added later on, and it avoided a decent fraction of the work porting to
Python 3. Have found users tend to like the labeling of messages, from INFO to
ERROR. We skip the time stamp on the console and send
This is my first post here. I have strong experience with JavaScript and
I'm lucky that I could move forward to Python.
What I miss in Python are immutable dictionaries. They are especially
useful for configurations and call functions which expect dictionary as
argument. In my opinion they would l
I like much of the thinking in Random's approach. But I still think None
isn't quite special enough to warrant it's own syntax.
However, his '(or None: name.strip()[4:].upper())' makes me realize that
what is being asked in all the '?(', '?.', '?[' syntax ideas is a kind of
ternary expression. Ex
https://www.python.org/dev/peps/pep-0416/
Also: https://pypi.python.org/pypi/frozendict
On Wed, Nov 29, 2017 at 9:30 AM, Asen Bozhilov
wrote:
> This is my first post here. I have strong experience with JavaScript and
> I'm lucky that I could move forward to Python.
> What I miss in Python are i
On Wed, Nov 29, 2017, at 12:30, Asen Bozhilov wrote:
> I would appreciate your opinions on the topic. Most interesting for me is
> why they are not already part of the language?
See the rejection notes at https://www.python.org/dev/peps/pep-0416/
___
Pyt
On Wed, Nov 29, 2017 at 7:21 AM, Daniel Moisset
wrote:
> As reference of prior art, there is https://pypi.python.org/pypi/munch in
> PyPI
>
Box is also popular as it permits deeper nesting:
https://pypi.python.org/pypi/python-box/ https://github.com/cdgriffith/Box
Addict is similar: https://pypi
Hi, IMHO the prior decision(s) are too conservative. Reading the bugs, we can
see lots of folks reinventing the wheel with common use cases for no good
reason. I also gave examples in the log4j, docs, and web apps world that these
levels are recognized needs.
An addition would represent a ve
> On Nov 29, 2017, at 12:40 PM, David Mertz wrote:
>
> I like much of the thinking in Random's approach. But I still think None
> isn't quite special enough to warrant it's own syntax.
>
> However, his '(or None: name.strip()[4:].upper())' makes me realize that what
> is being asked in all th
On Nov 29, 2017, at 12:40, David Mertz wrote:
> I think some syntax could be possible to only "catch" some exceptions and let
> others propagate. Maybe:
>
>val = name.strip()[4:].upper() except (AttributeError, KeyError): -1
>
> I don't really like throwing a colon in an expression though
2017-11-29 18:30 GMT+01:00 Asen Bozhilov :
> I'd like to propose also literaling syntax for immutable dictionaries.
>
> immutable_dict = (
> 'key1' : 'value1',
> 'key2' : 'value2'
> )
Since Python 3.3, you can write:
vstinner@apu$ python3
Python 3.6.3 (default, Oct 9 2017, 12:07:10)
>>>
Steven D'Aprano writes:
> > The two iterators have the same duck-type, the generator is different.
>
> How is the generator different?
My bad, I got the comparison backward. The generator *is* different,
but it's because the generator has *extra* public methods, not fewer.
Sorry for the noi
David Mertz wrote:
> https://www.python.org/dev/peps/pep-0416/
PEP 351 (also rejected) is related to this.
-Barry
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python
Serhiy Storchaka wrote:
> In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
> already was deprecated when the plistlib module was added to the regular
> stdlib in Python 2.6.
>
> Raymond noticed that that capability seemed nice to have.
So nice in fact that I'm sure I've reim
Nathan Schneider wrote:
> I think it would be interesting to investigate how assert statements are
> used in the wild. I can think of three kinds of uses:
assert statements are also a form of executable documentation. It says
something like "I think the internal state of my code must be this wa
True enough. I remember the prior discussion, but didn't look up the PEP
number. I know it's hard to revisit these ideas, but occasionally it works,
especially if a nicer spelling is found (Barry proposed some a bit
different than my ideas)
On Nov 29, 2017 9:55 AM, "Eric V. Smith" wrote:
On Nov
On 29 November 2017 at 20:11, Barry Warsaw wrote:
> Serhiy Storchaka wrote:
> > In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
> > already was deprecated when the plistlib module was added to the regular
> > stdlib in Python 2.6.
> >
> > Raymond noticed that that capabilit
Nick Coghlan wrote:
What about more English-like syntax:
X or else Y
The problem with constructs like this is that they look like they
should mean the same thing as "X or Y".
How about:
x otherwise y
It looks different enough from "or" that you're not going
to accidentally read it that
Stephan Houben wrote:
X or else Y
Sounds like a Python dialect for Mafia use.
customer.repay(loan) or else apply(baseball_bat, customer.kneecaps)
--
Greg
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listi
Stephan Houben wrote:
A if is not None else C
Reading that gives me the feeling that something in my
brain has slipped a tooth.
It would read better with some kind of pronoun in there:
A if it is not None else C
Hypercard's Hypertalk had a special variable "it" that
worked sort of like t
C Anthony Risinger wrote:
Is __len__ a viable option now that __length_hint__ has been identified
for hints?
No, I misremembered that feature, sorry.
But I still don't like the idea of changing behaviour
depending on whether the RHS "looks like" an iterator
or not.
I'm not sure how to explain
Op 29 nov. 2017 22:35 schreef "Greg Ewing" :
It would read better with some kind of pronoun in there:
A if it is not None else C
Hypercard's Hypertalk had a special variable "it" that
worked sort of like that.
I considered that, but there are two issues.
1. Backward-incompatible change
C Anthony Risinger wrote:
`a, b, ...` to me says "pull out a and b and throw away the rest"...
> The mere presence of more
characters (...) implies something else will *happen* to the remaining
items, not that they will be skipped.
It seems that many people think about unpacking rather
diffe
On Thu, Nov 30, 2017 at 8:56 AM, Stephan Houben wrote:
>
>
> Op 29 nov. 2017 22:35 schreef "Greg Ewing" :
>
>
> It would read better with some kind of pronoun in there:
>
>A if it is not None else C
>
> Hypercard's Hypertalk had a special variable "it" that
> worked sort of like that.
>
>
> I
On 11/29/2017 08:31 PM, Barry Warsaw wrote:
Nathan Schneider wrote:
I think it would be interesting to investigate how assert statements are
used in the wild. I can think of three kinds of uses:
assert statements are also a form of executable documentation. It says
something like "I think t
On Wed, Nov 29, 2017 at 06:49:14AM -0800, David Mertz wrote:
> I didn't say no use case exists, but rather "too special case." And/or
> shortcutting is great, but truthiness feels much more general than noneness
> to me.
Of course truthiness is much more general than Noneness -- and that's
precis
On 2017-11-29 21:27, Greg Ewing wrote:
Nick Coghlan wrote:
What about more English-like syntax:
X or else Y
The problem with constructs like this is that they look like they
should mean the same thing as "X or Y".
How about:
x otherwise y
It looks different enough from "or" that you
On 2017-11-29 14:21, Greg Ewing wrote:
C Anthony Risinger wrote:
`a, b, ...` to me says "pull out a and b and throw away the rest"...
> The mere presence of more
characters (...) implies something else will *happen* to the remaining
items, not that they will be skipped.
It seems that many
On Wed, Nov 29, 2017 at 12:52 AM, Serhiy Storchaka
wrote:
> This is a dict subclass which allows to access items as attributes.
>
> d = plistlib.Dict()
> d['a'] = 1
> assert d.a == 1
> d.b = 2
> assert d['b'] == 2
>
> What do you think about reviving this type as general purpose type in
> colle
On 11/29/2017 03:34 PM, Chris Barker wrote:
Am I I the only one that thinks this is a "Bad Idea"?
No, you're not.
For me, it simply confuses even more the question of "is this code or is this
data?" -- which is a difficult enough
design question in a dynamic language.
As one of those who
On 29/11/2017 23:34, Chris Barker wrote:
On Wed, Nov 29, 2017 at 12:52 AM, Serhiy Storchaka
mailto:[email protected]>> wrote:
This is a dict subclass which allows to access items as attributes.
d = plistlib.Dict()
d['a'] = 1
assert d.a == 1
d.b = 2
assert d['b'] ==
On 29/11/2017 17:30, Asen Bozhilov wrote:
This is my first post here. I have strong experience with JavaScript
and I'm lucky that I could move forward to Python.
What I miss in Python are immutable dictionaries. They are especially
useful for configurations and call functions which expect dict
I, too, think that this is too special a case for a dedicated syntax but so
far I prefer:
x None-or y
The meaning is more clear to me. None-or is like regular or except that y
is evaluated only if x is None.
On Thu, Nov 30, 2017 at 2:35 AM, MRAB wrote:
> On 2017-11-29 21:27, Greg Ewing wrote
On Wed, Nov 29, 2017 at 10:52:51AM +0200, Serhiy Storchaka wrote:
> In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
> already was deprecated when the plistlib module was added to the regular
> stdlib in Python 2.6.
>
> This is a dict subclass which allows to access items
On Thu, Nov 30, 2017 at 10:49:19AM +1300, Greg Ewing wrote:
> C Anthony Risinger wrote:
> >Is __len__ a viable option now that __length_hint__ has been identified
> >for hints?
>
> No, I misremembered that feature, sorry.
>
> But I still don't like the idea of changing behaviour
> depending on w
On Thu, Nov 30, 2017 at 11:21:48AM +1300, Greg Ewing wrote:
> It seems that many people think about unpacking rather
> differently from the way I do. I think the difference
> is procedural vs. declarative.
>
> To my way of thinking, something like
>
>a, b, c = x
>
> is a pattern-matching op
On Wed, Nov 29, 2017 at 03:08:43PM -0800, Brendan Barnwell wrote:
> On 2017-11-29 14:21, Greg Ewing wrote:
> >On the other hand, some people seem to be interpreting
> >the word "unpack" as in "unpack a suitcase", i.e. the
> >suitcase is empty afterwards. But unpacking has never
> >meant that in Py
On 2017-11-29 20:43, Steven D'Aprano wrote:
At the point that you are conjuring from thin air an invisible suitcase
that is an exact clone of the original suitcase, in order to unpack the
clone without disturbing the original, I think the metaphor is so far
from the real-world unpacking of suitca
Brendan Barnwell wrote:
That's an interesting analysis, but I don't think your view is
really the right one. It *is* unpacking a suitcase, it's just that *if
necessary* the suitcase is constructed just in time for you to unpack
it.
I don't think that's right. An iterator created from a seque
On 28/11/2017 23:15, Alon Snir wrote:
> On Wed, Nov 29, 2017 at 5:46 AM, Alon Snir wrote:
>> I would like to mention that the issue of assignment to a target list, is
>> also relevant to the case of elementwise assignment to a mutable sequence
>> (e.g. lists and arrays). Here as well, the rhs
62 matches
Mail list logo
