31.10.18 21:23, Robert Vanden Eynde пише:
Should I write a PEP even though I know it's going to be rejected
because the mailing list was not really into it ?
It is better to not do this. PEP 572 was initially written with the
intention to be rejected.
On Thu, Nov 01, 2018 at 09:36:19PM +0200, Serhiy Storchaka wrote:
> 31.10.18 13:07, Antoine Pitrou пише:
> >l.pop(default=...) has the potential to be multi-thread-safe, while
> >your alternatives haven't.
>
> The multi-thread-safe alternative is:
>
> try:
> value = l.pop()
> exce
On Fri, Nov 02, 2018 at 10:48:22AM +0200, Serhiy Storchaka wrote:
> 31.10.18 21:23, Robert Vanden Eynde пише:
> >Should I write a PEP even though I know it's going to be rejected
> >because the mailing list was not really into it ?
I disagree that "the mailing list was not really into it".
So fa
> So far, I count 12 people who responded to the original post by
> Giampaolo. By my count, I see:
>
> * five people in favour;
> * three people against, or see no need for it;
> * four people I can't tell if they are for or against,
> (possibly neutral?) [1]
For the little it's worth I'm +1
On 11/2/18 7:39 AM, Anders Hovmöller wrote:>
>> So far, I count 12 people who responded to the original post by
>> Giampaolo. By my count, I see:
>>
>> * five people in favour;
>> * three people against, or see no need for it;
>> * four people I can't tell if they are for or against,
>> (possib
Is there any reason why date, datetime, and UUID objects automatically
serialize to default strings using the csv module, but json.dumps throws an
error as a default? i.e.
import csv
import json
import io
from datetime import date
stream = io.StringIO()
writer = csv.writer(stream)
writer.writerow
First, this list is not appropriate. You should ask such a question in
python-list.
Second, JSON is a specific serialization format that explicitly rejects
datetime objects in *all* the languages with JSON libraries. You can only
use date objects in JSON if you control or understand both serializa
Serialization of those data types is not defined in the JSON standard:
https://www.json.org/
so you have to extend the parser/serializers to support them.
On 02.11.2018 17:19, Philip Martin wrote:
> Is there any reason why date, datetime, and UUID objects automatically
> serialize to default str
On Thu, Nov 1, 2018 at 8:34 PM, Steven D'Aprano wrote:
> The bottom line is, if I understand your proposal, the functionality
> already exists. All you need do is subclass dict and give it a
> __missing__ method which does what you want.
or subclass dict and give it a "setdefault_call") method
On Fri, Nov 2, 2018 at 3:59 AM, Steven D'Aprano wrote:
> - I'm not volunteering to do the work (I don't know enough C to write
> a patch). Unless somebody has a patch, we can't expect the core devs
> who aren't interested in this feature to write it.
>
> (Hence, status quo wins a stalemate.)
On Fri, Nov 2, 2018 at 9:31 AM, M.-A. Lemburg wrote:
> Serialization of those data types is not defined in the JSON standard:
>
> https://www.json.org/
That being said, ISO 8601 is a standard for datetime stamps, and a defacto
one for JSON
So building encoding of datetime into Python's json en
My bad. I think I need to clarify my objective. I definitely understand the
issues regarding serialization/deserialization on JSON, i.e. decimals as
strings, etc., and hooking in a default serializer function is easy enough.
I guess my question is more related to why the csv writer and DictWriter
d
Andre Delfino writes:
> Frequently, while globbing, one needs to work with multiple extensions. I’d
> like to propose for fnmatch.filter to handle a tuple of patterns (while
> preserving the single str argument functionality, alas str.endswith),
This is one of those famous 3-line functions, th
On Sat, Nov 3, 2018 at 4:49 AM Stephen J. Turnbull
wrote:
>
> Andre Delfino writes:
>
> > Frequently, while globbing, one needs to work with multiple extensions. I’d
> > like to propose for fnmatch.filter to handle a tuple of patterns (while
> > preserving the single str argument functionality,
Just a little improvement: you don't need the l local variable, you can just
call append:
d.setdefault(foo, []).append(bar)
And correspondingly:
d[foo].append(bar)
> On 2 Nov 2018, at 17:52, Chris Barker via Python-ideas
> wrote:
>
>> On Thu, Nov 1, 2018 at 8:34 PM, Steven D'Aprano wrote:
>
On Fri, Nov 2, 2018 at 10:31 AM Philip Martin
wrote:
> [Why don't] csv writer and DictWriter provide ...
> serialization/deserialization hooks?
>
Do you have a specific use-case in mind?
My intuition is that comprehensions provide sufficient functionality such
that changing the csv module inter
JSON-LD supports datetimes (as e.g. IS8601 xsd:datetimes)
https://www.w3.org/TR/json-ld11/#typed-values
Jsonpickle (Python, JS, ) supports datetimes, numpy arrays, pandas
dataframes
https://github.com/jsonpickle/jsonpickle
JSON5 supports comments in JSON.
https://github.com/json5/json5/issues/3
On Fri, Nov 02, 2018 at 09:52:24AM -0700, Chris Barker wrote:
> On Thu, Nov 1, 2018 at 8:34 PM, Steven D'Aprano wrote:
>
> > The bottom line is, if I understand your proposal, the functionality
> > already exists. All you need do is subclass dict and give it a
> > __missing__ method which does wh
> defaultdict:
>- takes a zero-argument factory function which is
> unconditionally called when the key is missing.
>
> Did I miss any?
>
> What we don't have is a version of setdefault where the default is
> evaluated only on need. That would be a great use-case for Call-By-Name
>
On Fri, Nov 2, 2018 at 5:25 PM Anders Hovmöller wrote:
> Could you explain what the difference is between defaultdicts "factory
> which is unconditionally called when the key is missing" and "the default
> is evaluated only on need"?
>
The distinction was the motivation for this thread: setdefau
On Sat, Nov 03, 2018 at 01:15:04AM +0100, Anders Hovmöller wrote:
>
> > defaultdict:
> >- takes a zero-argument factory function which is
> > unconditionally called when the key is missing.
> >
> > Did I miss any?
> >
> > What we don't have is a version of setdefault where the default
21 matches
Mail list logo
