[Python-ideas] Re: Calendar.year()

Abdur-Rahmaan Janhangeer Wrote in message:r > Greetings list,In the calendar module, i find it terribly unintuitive to have > a calendar.month but not a calendar.year, the default being > calendar.calendarSuggestion: replace calendar.calendar by > calendar.yearYours,Abdur-Rahmaan Janhangeerpyth

[Python-ideas] Re: Renaming json.load()

On 11/27/2019 3:24 PM, Abdur-Rahmaan Janhangeer wrote: Greetings list, Using 3.7, in json module of the std lib there is json.load and json.loads . I gather json.loads is more used to convert string to dict structure. json.load might cause (it already causes) confusions. Suggestion: Rename

[Python-ideas] Re: Calendar.year()

> Replacing it would break backward compatibility. But adding a year function as an alias for calendar wouldn’t. And you could note in > the docs that year is preferred for new code, or even deprecate the old name over a few versions if it seems worth it. > What about prcal (as opposed to pryear)

[Python-ideas] Re: Renaming json.load()

On Nov 27, 2019, at 12:27, Abdur-Rahmaan Janhangeer wrote: > > Using 3.7, in json module of the std lib there is json.load and json.loads . > I gather json.loads is more used to convert string to dict structure. Yes, loads is to load from a string; load is used to load from a file (or file-li

[Python-ideas] Re: Calendar.year()

On Nov 27, 2019, at 12:39, Abdur-Rahmaan Janhangeer wrote: > > > In the calendar module, i find it terribly unintuitive to have a > calendar.month but not a calendar.year, the default being calendar.calendar > > Suggestion: replace calendar.calendar by calendar.year Replacing it would break

[Python-ideas] Re: Renaming json.load()

Those functions, ``load`` and ``loads``, for better or worse, are a standard across many modules. Now that the standard has been established, it's good to stick with it. Good interface design needs to consider familiarity as well as what might be best without any history. On Wed, Nov 27, 2019 at 1

[Python-ideas] Calendar.year()

Greetings list, In the calendar module, i find it terribly unintuitive to have a calendar.month but not a calendar.year, the default being calendar.calendar Suggestion: replace calendar.calendar by calendar.year Yours, Abdur-Rahmaan Janhangeer pythonmembers.club

[Python-ideas] Renaming json.load()

Greetings list, Using 3.7, in json module of the std lib there is json.load and json.loads . I gather json.loads is more used to convert string to dict structure. json.load might cause (it already causes) confusions. Suggestion: Rename json.load() so as not to confuse with json.loads() ^^_ Yours

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

On Nov 27, 2019, at 09:13, Serhiy Storchaka wrote: > > PEP 8 is the stdlib style guide, and the type annotations are not > used in the stdib. PEP 8 already has guidelines for annotations. For example: > Function annotations should use the normal rules for colons and always have > spaces around

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

Stefano Borini Wrote in message:r > This may be a pet peeve of mine, but with the introduction of typehints, more > and more function definitions have become longer than 80characters. This used > to seldom happen in the past.The problem, as I see it, is that there seem to > be a general tendenc

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

I think its fine if Black and PEP 8 disagree. PEP 8 is meant for humans who want to lay out their code maximally readable and consistent, but in many cases allows multiple ways (if both are readable or if it depends on other context). PEP 8 also covers things like naming conventions and how to use

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

Thanks. I'll check black behavior and file an issue there tonight. In any case, the point stands. I think new, rather expected case should be clarified explicitly in the pep. On Wed, 27 Nov 2019 at 14:53, Ivan Levkivskyi wrote: > > IIRC, black actually uses the first style you mention, so maybe y

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

Black is a bit weird in some other ways. Like preferring " over '. He has an agenda, he's not trying to codify the de facto style :( > On 27 Nov 2019, at 15:56, Ivan Levkivskyi wrote: > >  > IIRC, black actually uses the first style you mention, so maybe you should > rather discuss it there f

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

IIRC, black actually uses the first style you mention, so maybe you should rather discuss it there first. Otherwise this will create a weird situation where one of the most popular auto-formatter formats code in violation of PEP 8. -- Ivan On Wed, 27 Nov 2019 at 11:42, Stefano Borini wrote: >

[Python-ideas] Update pep8 for stressing type hinted long parameter in functions

This may be a pet peeve of mine, but with the introduction of type hints, more and more function definitions have become longer than 80 characters. This used to seldom happen in the past. The problem, as I see it, is that there seem to be a general tendency to use this way of indenting, e.g. see (a