Hi,
csv.DictReader uses OrderedDict by default, from Python 3.6.
But it doesn't make sense anymore, like namedtuple._asdict().
How about changing default dict type back to regular dict.
Python is widely used for handling learge data. So I think
changing default dict type to OrderedDict was
On 1/30/2019 8:45 PM, Raymond Hettinger wrote:
On Jan 30, 2019, at 3:41 PM, Glenn Linderman wrote:
Would it be practical to add deprecated methods to regular dict for the OrderedDict
reordering methods that raise with an error suggesting "To use this method, convert
dict to OrderedDict." (or
> On Jan 30, 2019, at 9:11 PM, Tim Delaney wrote:
>
> Alternatively, would it be viable to make OrderedDict work in a way that so
> long as you don't use any reordering operations it's essentially just a very
> thin layer on top of a dict,
There's all kinds of tricks we could do but none
On Thu, 31 Jan 2019 at 15:46, Raymond Hettinger
wrote:
>
> > Would it be practical to add deprecated methods to regular dict for the
> OrderedDict reordering methods that raise with an error suggesting "To use
> this method, convert dict to OrderedDict." (or some better wording).
>
> That's an
> On Jan 30, 2019, at 6:00 PM, David Mertz wrote:
>
> Ditto +1 option 4
>
> On Wed, Jan 30, 2019, 5:56 PM Paul Moore On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger
> wrote:
> > My recommendation is Option 4 as being less disruptive and more beneficial
> > than the other options. In the
On Wed, Jan 30, 2019 at 2:34 PM Raymond Hettinger
wrote:
> Now that regular dicts are ordered and compact, it makes more sense for the
> _asdict() method to create a regular dict (as it did in its early days)
> rather than an OrderedDict. The regular dict is much smaller, much faster,
> and
Ditto +1 option 4
On Wed, Jan 30, 2019, 5:56 PM Paul Moore On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger
> wrote:
> > My recommendation is Option 4 as being less disruptive and more
> beneficial than the other options. In the unlikely event that anyone is
> currently depending on the
On Jan 30, 2019, at 14:32, Raymond Hettinger
wrote:
>
> Now that regular dicts are ordered and compact, it makes more sense for the
> _asdict() method to create a regular dict (as it did in its early days)
> rather than an OrderedDict. The regular dict is much smaller, much faster,
> and
On Wed, Jan 30, 2019 at 2:32 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> Now that regular dicts are ordered and compact, it makes more sense for
> the _asdict() method to create a regular dict (as it did in its early days)
> rather than an OrderedDict. The regular dict is much
On 1/30/2019 2:32 PM, Raymond Hettinger wrote:
Now that regular dicts are ordered and compact, it makes more sense for the
_asdict() method to create a regular dict (as it did in its early days) rather
than an OrderedDict.
...
Option 4) Just make the change directly in 3.8,
On 01/30/2019 02:55 PM, Paul Moore wrote:
On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger
wrote:
My recommendation is Option 4 as being less disruptive and more beneficial than
the other options. In the unlikely event that anyone is currently depending on
the reordering methods for the
Hi Python community folk!
As we've done for the past many years, Python is hoping to participate
in Google Summer of Code. This is a neat program where students write
code over the (northern hemisphere) summer under the tutelage of open
source mentors and get paid: we provide the project ideas,
On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger
wrote:
> My recommendation is Option 4 as being less disruptive and more beneficial
> than the other options. In the unlikely event that anyone is currently
> depending on the reordering methods for the output of _asdict(), the
> remediation is
Now that regular dicts are ordered and compact, it makes more sense for the
_asdict() method to create a regular dict (as it did in its early days) rather
than an OrderedDict. The regular dict is much smaller, much faster, and has a
much cleaner looking repr. It would also help namedtuple()
Stefan Behnel wrote:
So … are you suggesting to use the webbrowser module inside of the REPL to
look up the exception message of the previously printed stack trace in
stack overflow when a user types "why()"?
"Python is searching for an answer to your question..."
--
Greg
On Wed, Jan 30, 2019 at 07:12:21PM +0100, Stefan Behnel
wrote:
> > I have a vague recollection that a certain computer system (Amiga?) had a
> > 'why' command. If it reported an error, you could type "why" and it would
> > give you more details.
> >
> > I suspect that all that was happening was
On 2019-01-30 18:12, Stefan Behnel wrote:
MRAB schrieb am 29.01.19 um 19:55:
On 2019-01-29 13:44, Nick Coghlan wrote:
FWIW, we have pretty decent evidence that error messages don't have to
provide a wonderful explanation on their own in order to be helpful:
they just need to be distinctive
MRAB schrieb am 29.01.19 um 19:55:
> On 2019-01-29 13:44, Nick Coghlan wrote:
>> FWIW, we have pretty decent evidence that error messages don't have to
>> provide a wonderful explanation on their own in order to be helpful:
>> they just need to be distinctive enough that a web search will
>>
Hello,
I'm sorry for posting here and not to python-announce, somehow I think
(perhaps naively) that it may be of interest to people who are
interested in Python development. At the very least, creation of the
original package is (very likely, I didn't trace up to that) was
discussed on
19 matches
Mail list logo
