On 30 March 2018 at 02:04, Clint Hepner wrote:
>
>> On 2018 Mar 29 , at 11:42 a, Julia Kim wrote:
>>
>> My suggestion is to change the syntax for creating an empty set and an empty
>> dictionary as following.
>>
>> an_empty_set = {}
>>
On 30 March 2018 at 02:53, Paul Moore wrote:
> On 29 March 2018 at 16:27, Nick Coghlan wrote:
>> On 28 March 2018 at 04:47, Paul Moore wrote:
>>> To me, that would be the ideal. I assume there are significant
>>> technical
> On 2018 Mar 29 , at 12:06 p, Chris Angelico wrote:
>
> On Fri, Mar 30, 2018 at 3:00 AM, Stephan Houben wrote:
>> Perhaps one day we will be able to use
>>
>> ∅
>>
>> for the empty set.
>> That would actually match conventional notation.
>>
>
>
> There are two chances of this happening, zero or none.
That would be the empty set, yes? ;-)
-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
You should probably first explain your use case -- why is it important to
your code to be able to use isinstance() on locks?
On Thu, Mar 29, 2018 at 2:43 AM, Jacco van Dorp
wrote:
> Currently, you cannot use isinstance checks on threading locks, because
> they're created
On 29/03/18 16:42, Julia Kim wrote:
My suggestion is to change the syntax for creating an empty set and an empty
dictionary as following.
an_empty_set = {}
an_empty_dictionary = {:}
Compatibility issues could be resolved with a program which takes a Python
program (codes) as a text and
On 29 March 2018 at 16:27, Nick Coghlan wrote:
> On 28 March 2018 at 04:47, Paul Moore wrote:
>> To me, that would be the ideal. I assume there are significant
>> technical challenges, though, as otherwise I'd have thought that would
>> have been the
On Fri, Mar 30, 2018 at 3:00 AM, Stephan Houben wrote:
> Perhaps one day we will be able to use
>
> ∅
>
> for the empty set.
> That would actually match conventional notation.
>
Maybe, but that symbol generally means the unique immutable empty set
in mathematics, so a
> On 2018 Mar 29 , at 11:42 a, Julia Kim wrote:
>
> My suggestion is to change the syntax for creating an empty set and an empty
> dictionary as following.
>
> an_empty_set = {}
> an_empty_dictionary = {:}
If you are willing to accept {:} as an empty dict, then
Perhaps one day we will be able to use
∅
for the empty set.
That would actually match conventional notation.
Note that this is not valid syntax today (not a legal Unicode identifier).
Stephan
Op do 29 mrt. 2018 17:49 schreef Chris Angelico :
> On Fri, Mar 30, 2018 at 2:42
On Fri, Mar 30, 2018 at 2:42 AM, Julia Kim wrote:
> My suggestion is to change the syntax for creating an empty set and an empty
> dictionary as following.
>
> an_empty_set = {}
> an_empty_dictionary = {:}
>
>
> Compatibility issues could be resolved with a program
My suggestion is to change the syntax for creating an empty set and an empty
dictionary as following.
an_empty_set = {}
an_empty_dictionary = {:}
Compatibility issues could be resolved with a program which takes a Python
program (codes) as a text and edits it.
Sent from my iPhone
On 28 March 2018 at 04:47, Paul Moore wrote:
> On 27 March 2018 at 19:43, Ethan Furman wrote:
>> On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote:
>>>
>>> On 27 March 2018 at 18:19, Guido van Rossum wrote:
>>
Hm, so maybe we shouldn't touch lambda, but
On 28 March 2018 at 03:19, Guido van Rossum wrote:
> On Tue, Mar 27, 2018 at 6:56 AM, Nick Coghlan wrote:
>>
>> [...] The implicit functions used in the
>> comprehension & generator expression cases are just potentially
>> simpler to handle, as we don't care
On 28 March 2018 at 00:52, Ethan Furman wrote:
> On 03/25/2018 09:46 AM, Ethan Furman wrote:
>>
>> On 03/24/2018 09:24 PM, Nick Coghlan wrote:
>>
>>> No, the fact that the expression defining the outermost iterable gets
>>> evaluated in the outer scope is behaviour that's
>>>
Hm, so maybe we shouldn't touch lambda, but we can at least fix the
scope issues for comprehensions and genexprs.
There may still be breakage, when the code defines a global x that is
overridden by a class-level x, and a class-level comprehension
references x assuming it to be the global.
Currently, you cannot use isinstance checks on threading locks, because
they're created by a factory function instead of being actual classes.
Now that we've got __subclasshook__ and __instancecheck__, is there
still a reason other than "history" that we can't use isinstance here ? There
could
17 matches
Mail list logo