On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg wrote:
> [...]
>
> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)
>
> [...]
Hi Marc-Andre,
Maybe just require senders to be members of the python.org domain, and
retain the release
Sounds like you might want the "Python Help" group on https;//
discuss.python.org - the dev conversation migrated there quite a while ago
now, so thighs channel is more or less announcements only.
Good luck with your project!
Kind regards,
Steve
On Thu, 5 Oct 2023 at 16:07, Guenther Sohler
Hi Chris,
Nice to see you on the list.
While this is definitely off-topic, I trust I might be given license by the
list's few remaining readers to point out that the match-case construct is
for _structural_ pattern matching. As I wrote in the latest Nutshell:
"Resist the temptation to use match
Well, the first comment is that this isn't really the best list to ask such
questions on, since it was created for the Python developers to discuss the
development of the language and its implementation. Further, such
discussions nowadays take place on discuss.python.org, and you can find
more
I don't remember it being mentioned, but much of the traffic recently
migrated from this list to https://discuss.python.org/c/core-dev/23, which
you may wish to keep in touch with.
Kind regards,
Steve
On Tue, Oct 25, 2022 at 7:53 AM Juan Cristóbal Quesada <
On Mon, Apr 4, 2022 at 4:13 PM Coyot Linden (Glenn Glazer) <
co...@lindenlab.com> wrote:
> I would like to point out another use case of triple quotes outside of
> docstrings. We do a lot of SQL here and so doing a parameterized query
> like:
>
> """SELECT foo
> FROM bar
> WHERE baz = %s"""
>
>
Not defining the semantics of annotations was a brave move, but
inevitably led to the situation where different use cases, all
quite reasonable, would spring into being. Now they have, the development
team has to decide a) which ones to sanction and b) which will be left out
in the cold.
I wish
Time for a __legacy__ package?
Kind regards,
Steve
On Sun, Mar 27, 2022 at 7:06 PM Paul Moore wrote:
> On Sun, 27 Mar 2022 at 17:11, Christopher Barker
> wrote:
> >
> > With the json package included, all they need to do is `import json`. If
> that wasn't there, they's look in PyPi for a
On Tue, Jan 11, 2022 at 6:24 PM Guido van Rossum wrote:
> I personally think F-strings should not be usable as docstrings. If you
> want a dynamically calculated docstring you should assign it dynamically,
> not smuggle it in using a string-like expression. We don't allow "blah {x}
>
On Tue, Nov 30, 2021 at 5:05 PM Steven D'Aprano wrote:
> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
> [...]
> Aside: I'm a little disappointed in the way the typing ecosystem has
> developed. What I understood was that we'd get type inference like ML or
> Haskell use, so we
On Mon, Nov 15, 2021 at 8:42 AM Kyle Stanley wrote:
> On Sat, Nov 13, 2021 at 5:04 PM wrote:
>
>>
>>
>> def 횑퓮햑풍표():
>>
> [... Python code it's easy to believe isn't grammatical ...]
> return ₛ
>>
>
> 0_o color me impressed, I did not think that would be legal syntax. Would
> be
Speaking as the author of the doc pages, I think I can safely say that
anyone who was smart enough to use asyncore/asychat back in the day (I used
it in "Python Web Programming") is almost certainly smart enough to have
migrated away from them long ago. They were an interesting approach to
I understood that _iterables_ are required to have an __iter__ method, not
iterators.
Therefore, are we simply discussing whether all iterators should be
iterable? At the moment the CPython implementation does't require that
AFAIK.
regards
Steve
On Tue, Sep 14, 2021 at 8:39 PM Guido van Rossum
I suspect it's the same motivation that makes us comment out a block of
code rather than deleting it, even though we know the VCS will let us
retirive it whenever we want. If I'm wrong it won't be fatal. Or surprising
;-)
Kind regards,
Steve
On Wed, Aug 25, 2021 at 8:53 PM Eric V. Smith wrote:
You forgot:
5. When I just don't damned well feel like it.
Kind regards,
Steve
On Wed, Aug 25, 2021 at 8:25 PM Brett Cannon wrote:
> I just wanted to apologize for any angst or noise my replies to Marco
> caused folks. I should have known that correcting Marco on how to address
> me would
Your inflated sense of your own significance is unfortunate, since it
appears to prohibit you from considering the possibility you might have
made a rather silly mistake here, and one which is calculated to move you
further away from your stated goals.
Kind regards,
Steve
On Tue, Aug 17, 2021
On Wed, Aug 11, 2021 at 7:09 AM Larry Hastings wrote:
> On 8/10/21 11:15 AM, Thomas Grainger wrote:
>
> Although the co_annoations code could intercept the NameError and replace
> return a ForwardRef object instead of the resolved name
>
>
> No, it should raise a NameError, just like any other
On Wed, Aug 11, 2021 at 2:27 PM Guido van Rossum wrote:
> As it happens, I have a working prototype of lazy in marshaling that would
> work well for this.
>
> Nice to see you keep the time machine in working order ...
Kind regards,
Steve
___
On Fri, Jul 2, 2021 at 12:47 AM wrote:
> Okay so I just code a little bit and I used the multiprocessing module but
> my code didn't work and I found the solution on Stack Overflow and it
> turned out to be not my mistake (which has never happened before I think).
> Instead I found out it's a
On Fri, May 28, 2021 at 10:26 PM Ethan Furman wrote:
> On 5/28/21 12:43 AM, Petr Viktorin wrote:
> > On 28. 05. 21 5:24, Ethan Furman wrote:
>
> >> class FlagWithMasks(IntFlag):
> >> DEFAULT = 0x0
> >>
> >> FIRST_MASK = 0xF
> >> FIRST_ROUND = 0x0
> >>
On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano
wrote:
> Steve
> (one of the other ones)
>
We are all other Steves!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
On Thu, May 13, 2021 at 9:18 AM Mark Shannon wrote:
> Hi Terry,
>
> On 13/05/2021 5:32 am, Terry Reedy wrote:
> > On 5/12/2021 1:40 PM, Mark Shannon wrote:
> >
> >> This is an informational PEP about a key part of our plan to improve
> >> CPython performance for 3.11 and beyond.
> >
> >> As
On Fri, Apr 16, 2021 at 7:15 PM Denis Kotov wrote:
> Ethan Furman wrote:
> > On 4/16/21 10:43 AM, redrad...@gmail.com wrote:
> > > Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU
> > > or read some articles ... otherwise I will need to spend too many time
> providing
DEFAULT_TIMESTAMP?
Kind regards,
Steve
On Wed, Apr 14, 2021 at 8:03 PM wrote:
> If the so, then a better name than NO_TIMESTAMP should be chosen, as the
> gzip specification does not allow for no timestamp.
> ___
> Python-Dev mailing list --
The old rule is best: be strict in what you produce and liberal i what you
accept.
Kind regards,
Steve
On Tue, Apr 13, 2021 at 12:52 AM Edwin Zimmerman
wrote:
> On 4/12/2021 6:34 PM, Brett Cannon wrote:
>
> Had the sentences ended at "confusing" or said something like "I don't
> think it's as
On Fri, Feb 19, 2021 at 10:53 PM Christian Heimes
wrote:
> On 19/02/2021 23.22, Stestagg wrote:
> > The thing that stood out from this conversation, for me, is: Releases
> > are too hard, and there’s a risk of not having enough volunteers as a
> > result.
> >
> > How hard is it to fix that?
>
>
emerged in
> the discussions.
> On 06.02.2021 23:58, Steve Holden wrote:
>
> My suggestion that it be introduced via __future__ due to its contentious
> nature met immediate resistance. No point going down that road.
>
> Kind regards,
> Steve
>
>
> On Sat, Feb 6, 2021 at
My suggestion that it be introduced via __future__ due to its contentious
nature met immediate resistance. No point going down that road.
Kind regards,
Steve
On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> With such a large new area of functionality
If the length of the name is any kind of issue, since the stdlib
only contains modules (and packages), why not just sys.stdlib_names?
On Mon, Jan 25, 2021 at 5:18 PM Victor Stinner wrote:
> Hi Bernat,
>
> "stdlib_module_names" was my first idea but it looks too long, so I
> chose
A general wish not to disadvantage those with older hardware any more than
they already are?
Just a shot in the dark.
On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith wrote:
>
>
> As a meta question: Is there a good reason to support binaries running on
> macOS earlier than ~
Fair enough.
On Fri, Nov 20, 2020 at 11:45 AM Thomas Wouters wrote:
>
>
> On Fri, Nov 20, 2020 at 8:38 AM Steve Holden wrote:
>
>> On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon wrote:
>>
>> All I will say is just because we aren't *required* to implement it in
&
On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon wrote:
>
>
> On Thu, Nov 19, 2020 at 5:16 AM Steve Holden wrote:
>
>> On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset
>> wrote:
>>
>>> [sorry for the duplicate, meant to reply-all]
>>>
>>> Tha
On Wed, Nov 18, 2020 at 7:45 PM Brett Cannon wrote:
>
>
> On Tue, Nov 17, 2020 at 10:16 PM Greg Ewing
> wrote:
>
>> On 18/11/20 4:36 pm, Larry Hastings wrote:
>> >
>> > But,
>> > the thinking went, you'd never want to examine the last value from a
>> > list generator, so it was more convenient
On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset wrote:
> [sorry for the duplicate, meant to reply-all]
>
> Thank you for this approach, I find it really helpful to put the
> conversation in these terms (semantics and guiding principles).
>
> It does help to rationalise discussion ;-)
> [...]
>
On Thu, Nov 12, 2020 at 8:49 PM Guido van Rossum wrote:
> The correct place for the docs for __cause__ and __context__ is in the
> section in the library reference about exceptions. There's quite a bit
> about them there already. That's where the tutorial should link as well.
>
> And now I ask
As I remember the webmaster@ discussions, Mats did go so far as to start a
re-write of the classes section, but it never got as far as a PR.
Kind regards,
Steve
On Fri, Nov 6, 2020 at 5:51 PM Guido van Rossum wrote:
> Ouch, that's bad. It seems the class tutorial could use an overhaul.
>
> We
On Wed, Oct 21, 2020 at 8:37 AM Paul Moore wrote:
> On Wed, 21 Oct 2020 at 08:14, Christian Heimes
> wrote:
> >
> > On 21/10/2020 00.14, Steven D'Aprano wrote:
> > > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> > >
> > >> What I don't see is where the money's coming from. It's
Since some code clearly accesses __version__, would it make sense to equip
all stdlib modules with a __version__ property that returned the Python
version, suitably prefixed?
Kind regards,
Steve
On Fri, Oct 16, 2020 at 5:28 AM Karthikeyan wrote:
> On Fri, Oct 16, 2020, 12:45 AM Serhiy
Full marks to the SC for transparency. That's a healthy sign that the
community acknowledges its disciplinary processes must also be open to
scrutiny, and rather better than dealing with matters in a Star Council.
Kind regards,
Steve
On Fri, Oct 9, 2020 at 12:10 AM Thomas Wouters wrote:
>
>
On Wed, Sep 16, 2020 at 3:53 PM Mark Shannon wrote:
> [...]
>
> maybe!(a.b)
>
> which would translate to:
>
> $tmp = a; None if $tmp is None else ($tmp.b)
>
> This reminds me very much of PL/1's "compile-time procedures," which
forty years ago were pretty much like PL/1
Sadly micropython is not intended to support numerical libraries and other
such complex modules: the support for the Python standard library is pretty
much non-existent.
Kind regards,
Steve
On Wed, Jul 22, 2020 at 3:10 PM Huang, Yang wrote:
> Thank you for all your comments.
>
> I cannot
While I understand the point of view that says that match ... :
should encapsulate a sequence of indented suites, it seems to me that
match/case/case/.../else has a natural affinity with
try/except/except/.../finally/else, and nobody seems to think that the
excepts should be indented. Or the
Given that case will be a keyword, what's the case (pun unintentional) for
indenting the case clauses? What's wrong with 'case' and 'else' both
indented the same as match? Without the keyword there'd be a case for
indenting, but with it I don't see the necessity.
Kind regards,
Steve
On Fri, Jul
do not necessarily require my opinions to be
thought reasonable, even by other reasonable people.
Kind regards,
Steve
On Mon, Jun 29, 2020 at 11:22 AM Nathaniel Smith wrote:
> On Mon, Jun 29, 2020 at 2:31 AM Steve Holden wrote:
> > The commit message used, however, reveals imple
It's broadly accepted among professional writers that the language used
should be acceptable and comprehensible to the audience. This seems
uncontentious.
Posting a straightforward change representing a relaxation of standards
(which were not in any case being enforced) should also be
On Wed, May 20, 2020 at 7:11 PM Jim J. Jewett wrote:
> David Mertz wrote:
>
> > Fwiw, I don't think it changes my order, but 'strict' is a better word
> than
> > 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> > they used "equal".
>
> I would say that 'equal' is worse
On Mon, Apr 6, 2020 at 8:04 PM Guido van Rossum wrote:
> On Mon, Apr 6, 2020 at 11:36 AM Steven D'Aprano
> wrote:
>
>>
>> Personally, I would not like to have to explain to newcomers why `match`
>> is a keyword but you can still use it as a function or variable, but not
>> other keywords like
On Wed, Mar 25, 2020 at 5:42 PM Dennis Sweeney
wrote:
> I'm removing the tuple feature from this PEP. So now, if I understand
> correctly, I don't think there's disagreement about behavior, just about
> how that behavior should be summarized in Python code.
> [...]
> return (the original
The webmaster list sends an auto-response to new posters. If something like
that could happen on python-dev too, as long as the advice was clear enough
the list could then simply ignore such requests, knowing that the
auto-responder had taken care of it. This could drive posters to
python-list or
Really webmas...@python.org would have been more appropriate, but I've
already copied that address on my direct reply to you. The python-dev list
is for discussions about the development of the language and its CPython
implementation.
Kind regards,
Steve
On Tue, Jan 28, 2020 at 7:20 PM Steve
I've verified this fix and changed the status to "commit review." I trust
that was the correct action.
Kind regards,
Steve Holden
On Thu, Jan 9, 2020 at 9:57 PM Cédric Krier via Python-Dev <
python-dev@python.org> wrote:
> Hi,
>
> Any chance to get this PR
In which case, wouldn't "_" make a better literal prefix than "i"?
A better comparison might be between _"..." and f"...".
regards
Steve Holden
On Thu, Dec 5, 2019 at 5:37 AM Serhiy Storchaka wrote:
> 04.12.19 16:02, Anders Munch пише:
> >
If using a dictionary but still requiring attribute access, techniques such
as those used at https://github.com/holdenweb/hw can be used to simply
client code.
Kind regards,
Steve Holden
On Wed, Oct 30, 2019 at 11:15 AM Oz Tiram wrote:
> Hi Steve,
>
> Thanks for your reply. While
,
Steve Holden
On Tue, Oct 29, 2019 at 10:59 PM Oz Tiram wrote:
> Hello Python-devs,
>
> The csv module is probably heavily utilized by newcomers to Python, being
> a very popular data exchange format.
> Although, there are better tools for processing tabular data like SQLite,
> or
It's not dead, it's just restin' after a particularly heavy release process.
regards
Steve Holden
On Mon, Sep 9, 2019 at 4:24 PM Rhodri James wrote:
> On 09/09/2019 15:51, brian.sk...@gmail.com wrote:
> > it's getting better?
>
> No it's not, it'll be stone d
traffic.
Good luck!
Steve Holden
On Fri, Aug 16, 2019 at 11:04 AM Ana Simion via Webmaster <
webmas...@python.org> wrote:
> Hello,
>
> Can you advise when you’re going to update Python to work with Mac OS X
> Catalina? I am running the beta of Mac OS X Catalina but am unable to
&g
On Mon, Aug 12, 2019 at 6:26 PM Terry Reedy wrote:
> On 8/8/2019 5:31 AM, Dima Tisnek wrote:
> [...]
>
> To me, this one of the major problems with the half-baked default.
> People who want string literals left as is sometimes get away with
> omitting explicit mention of that fact, but sometimes
the ground for the eventual introduction of the syntax error.
Steve Holden
On Sat, Aug 10, 2019 at 8:07 AM Serhiy Storchaka
wrote:
> 10.08.19 02:04, Gregory P. Smith пише:
> > I've merged the PR reverting the behavior in 3.8 and am doing the same
> > in the master branch.
>
> I w
incompatibility there would surely be general delight.
Kind regards,
Steve Holden
On Wed, Aug 7, 2019 at 8:19 PM eryk sun wrote:
> On 8/7/19, Steve Dower wrote:
> >
> > * change the PyErr_SetExcFromWindowsErrWithFilenameObjects function to
> > append (or chain) an extr
On Thu, Jul 25, 2019 at 4:01 AM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> I considered an alternative: return True if the underlying dicts were
> identical or equal, and raise an Exception otherwise.
> But I soon decided that this was a terrible idea: it could hide a bug by
>
PEP 8 would concur, whatever the current preferred style was. Under "Naming
Conventions":
"""New modules and packages (including third party frameworks) should be
written to these standards, but where an existing library has a different
style, internal consistency is preferred."""
The
ing the need to
seek assistance elsewhere. We see remarkably little spam, so moderating the
list isn't an issue and I've been doing that unaided for over a year
without noticing.
Kind regards,
Steve Holden
On Mon, Jul 8, 2019 at 11:56 PM Ethan Furman wrote:
> On 07/08/2019 03:12 PM, Steve
. The duties aren't
heavy, but the traffic is fairly regular and most of it benefits from being
answered sooner rather than later. So if anyone wants to pitch in, you'll
be welcomed.
Kind regards,
Steve Holden
On Mon, Jul 8, 2019 at 10:28 PM Barry Warsaw wrote:
> On Jul 8, 2019, at 12:56, Ba
On Tue, Jul 2, 2019 at 4:24 PM wrote:
> It seems to me that the desired behavior here is closest to
> 'str.replace()' out of all the options discussed, just with the constraint
> of being limited to either the start or the end of the string. (Thus the
> .lreplace() and .rreplace() option
Excellent thought.
On Fri, Jun 28, 2019 at 6:49 PM Ned Deily wrote:
>
> On Jun 28, 2019, at 12:56, Mariatta wrote:
> > Some of the items brought up during the language summit:
> > [...]
> > - we should be updating devguide ahead of the actual migration, so core
> developers and release
details at Python-list Info Page
<https://mail.python.org/mailman/listinfo/python-list>.
Kind regards,
Steve Holden
On Thu, Jun 20, 2019 at 3:40 AM Ed Peschko wrote:
> all,
>
> I'm writing a function meant to print out the context of a given
> function call when executed -
On Tue, Jun 18, 2019 at 9:37 PM Steve Dower wrote:
> On 18Jun2019 1025, Stephen J. Turnbull wrote:
> > Oleg Broytman writes:
> > > On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com
> wrote:
> >
> > > > Why don't we check the architecture using js and provide the
> > > >
Perhaps if PEP 594 is seen to be moving ahead towards a slimmer Python (4?)
stdlib, it might encourage the development of a PEP to take over
maintenance of dead parrots. They might be recruited by the offer of some
way to at least publish a supported bundle via the same (python.org) site
that
I'm guessing the reason is to remove the overhead of keeping the dictionary
up to date during function execution when no Python code needs access to it.
On Mon, May 27, 2019 at 8:10 PM Richard Damon
wrote:
> On 5/27/19 2:05 PM, Terry Reedy wrote:
> > On 5/27/2019 9:52 AM, Richard Damon wrote:
This whole vexing issue isn't going to be solved with any simple fix. A
tool that could identify upcoming trouble spots might or might not be
helpful.
Or perhaps it could be implemented as a __future__ feature, so that those
who choose not to use it during development see no change.
The primary
at doesn't involve lots of dev time then perhaps the PSF could be
involved? I presume the Steering Committee are the people to consider
directions like this.
Steve Holden
On Thu, May 23, 2019 at 7:03 PM Barry Warsaw wrote:
> On May 20, 2019, at 13:15, Christian Heimes wrote:
> >
&g
It might also serve to identify those with an interest in maintaining the
non-core packages, which might even be given some special status on PyPI.
On Thu, May 23, 2019 at 9:01 AM Alex Walters
wrote:
> I've watched the entire thread and its taken me a few days to put a finger
> on what bothers
Besides which, it would be lovely to have a major release that didn't
involve any pain at all for the majority of users!
Our erstwhile BDFL always eschewed two-digit version identifiers- due to
the possibility for confusion about collating sequence, I beleive.. We
should honour his preferences
Good point!
On Tue, May 21, 2019 at 2:01 PM Paul Moore wrote:
> On Tue, 21 May 2019 at 13:50, Steve Holden wrote:
> >
> > That seems entirely reasonable. I wonder if the larger community could
> somehow form an organization (the Dead Parrot SIG?) that would at least
&g
That seems entirely reasonable. I wonder if the larger community could
somehow form an organization (the Dead Parrot SIG?) that would at least
curate and monitor efforts to ensure their continued utility?
On Tue, May 21, 2019 at 1:40 PM Christian Heimes
wrote:
> On 21/05/2019 14.06, Anders
It's covered in "Python in a Nutshell," Alex Martelli having been a
promoter of its ability simplify many utility programs for a long time.
Not that that's any guide as to what should be in 3.10, by which time we'll
be four minor releases out of date anyway.
On Tue, May 21, 2019 at 9:16 AM
I suspect this discussion would be better moved to python-ideas, since it
seems clear there needs to be some work on determining the exact
requirements
On Sat, May 18, 2019 at 4:03 PM Dan Ryan wrote:
> It probably makes the most sense to formally outline all of the behavioral
> changes,
As a mere user I'd like to thank the developer team for biting this bullet.
Remembering the transition to Git I am sure that the further
democratisation (?) of the development process will similarly increase the
diversity and scope of the development effort.
It will indeed be a significant effort
What's not to like?
On Tue, May 7, 2019 at 2:31 AM Glenn Linderman
wrote:
> On 5/6/2019 5:39 PM, Eric V. Smith wrote:
>
> Last fall Larry Hastings made a suggestion for adding a way to make
> so-called "print-based debugging" easier with f-strings. Basically the
> approach is that f-strings
Looks like the failure is due to absence of a News entry. Maybe add a "skip
news" label if this doesn't need to be documented?
Kind regards.
Steve Holden
On Fri, May 3, 2019 at 9:48 AM Srinivas Reddy Thatiparthy <
thatiparthysreeni...@gmail.com> wrote:
> Hi,
>The P
On Fri, Mar 22, 2019 at 8:43 AM Victor Stinner wrote:
> Le ven. 22 mars 2019 à 09:16, Inada Naoki a
> écrit :
> > > > We have `socket.error` for long time.
> > >
> > > And it's perfectly fine, no?
> > >
> >
> > Yes. Waiting 10+ years to remove aliases is fine.
>
> [...]
>
> Right now, the
On Thu, Mar 21, 2019 at 11:33 AM Antoine Pitrou wrote:
> [...]
>
> Most users and applications should /never/ care about the order of XML
> attributes.
>
> Regards
>
> Antoine
>
Especially as the standards specifically say that ordering has no semantic
impact.
Byte-by-byte comparison of XML is
is needed, delegate it to the PSF! I'd
rather have you pushing Python forward ;-).
Finally, thanks again to everyone who contributes, particularly for
managing to hide a great deal of Python's modern-day complexity from those
who neither want nor need to know about it. Ultimately I thin
be
preferable?
Kind regards
Steve Holden
On Wed, Feb 27, 2019 at 3:13 PM Paul Ganssle wrote:
>
> On 2/26/19 7:03 PM, Chris Barker via Python-Dev wrote:
>
> This thread petered out, seemingly with a consensus that we should update
> the docs -- is anyone doing that?
>
> I don't
While these are interesting ideas, wouldn't it be better to leave this kind
of packaging to snap and similar utilities that bundle the language support
and libraries to allow simple isolated installation.
Kind regards
Steve Holden
On Tue, Feb 26, 2019 at 10:05 PM Neil Schemenauer
wrote
-- Forwarded message -
From: Steve Holden
Date: Thu, Jan 31, 2019 at 11:05 AM
Subject: Re: [Python-Dev] How about updating OrderedDict in csv and
configparser to regular dict?
To: INADA Naoki
And I see that such a patch is now merged. Thanks, Raymond
.
regards
Steve Holden
On Thu, Jan 31, 2019 at 7:55 AM INADA Naoki wrote:
> 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.
>
>
Like everyone else, I am sorry to hear this news, and extend my sympathies.
It's marvellous that you are still able to work on Python at all, still.
Since you have to be careful not to do too much, you will just have to
choose your battles carefully. Thank you for your many contributions to
Python
be even more strident when a library module is a
basic version, not to be used for production purposes.
This inevitably means, however, that there will be lag in the
documentation, which generally speaking lags current best practices.
Steve Holden
* I am not a significant contributor to the code
the PSF to manage such
activity.
Following the debate with interest, but mostly lurking due to my usual
absence of skin in the game. Bonne chance!
regards
Steve
Steve Holden
On Fri, Oct 26, 2018 at 6:17 PM, Brett Cannon wrote:
>
>
> On Tue, 23 Oct 2018 at 13:20, Jeroen Demeyer wrote:
This is terrific work. We all know that the best way to encourage
contributors is to use their usable contributions. Thank you very much,
Stephane and Victor (again)!
Steve Holden
On Sat, Oct 20, 2018 at 10:32 AM, Stephane Wirtel
wrote:
> On 10/20, Victor Stinner wrote:
>
>> Le
I'm afraid Kristjan left CCP some time ago, and may not subscribe to this
list any more.
Steve Holden
On Tue, Sep 25, 2018 at 4:23 PM Antoine Pitrou wrote:
> On Tue, 25 Sep 2018 09:09:26 -0600
> Eric Snow wrote:
> > On Tue, Sep 25, 2018 at 1:45 AM Victor Stinner
> wrote:
>
You can find information about python-list at
https://mail.python.org/mailman/listinfo/python-list
regards
Steve Holden
On Tue, Sep 18, 2018 at 4:28 AM Ryan Gonzalez wrote:
> Python-dev is for development *of* Python, not *in* Python! You want
> python-list instead.
>
> Also, m
On Sun, Sep 9, 2018 at 5:24 AM Joseph C. Sible
wrote:
> On Sat, Sep 8, 2018 at 11:47 PM Tim Peters wrote:
> [...]
> > As to why they want an address, you'll have to ask a
> > lawyer! There aren't any on this list. So, if you really want to
> > pursue this, I suggest you direct the question
d as
PEP 8 reminds us, change made for purely stylistic reasons threatens to
introduce new bugs.
It's not obvious how much of the developer documentation you've seen, so it
might be worth mentioning https://devguide.python.org/ as a good starting
point for anyone wanting to contribute.
regards
St
On Sun, Jul 22, 2018 at 12:14 AM, Guido van Rossum wrote:
> [...]
> The new BDFL may be less demanding though. :=)
>
I sincerely hope not.
regards
Steve
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, Jul 17, 2018 at 11:44 PM, Paul G wrote:
> In many languages numeric types can't hold arbitrarily large values, and I
> for one hadn't really previously recognized that if you read in a numeric
> value with an exponent that it would be represented *exactly* in memory
> (and thus one
On Thu, Jul 12, 2018 at 6:21 PM, Barry Warsaw wrote:
> [...]
>
> I was -1 as well, but I’d say I’m a firm +0 now[*]. I like how many of
> the problematic syntactic and semantic issues have been narrowed and
> prohibited, and I can see myself using this sparingly.
>
[...]
I think
one floating-point zero.
Steve Holden
On Thu, Jul 12, 2018 at 9:55 AM, Alex Walters
wrote:
>
>
> > -Original Message-
> > From: Python-Dev > list=sdamon@python.org> On Behalf Of Victor Stinner
> > Sent: Thursday, July 12, 2018 4:01 AM
> > To:
On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola'
wrote:
> [...]
> I find that (space between the parentheses of a function call statement)
> too unnatural as a place where to put an assignment. It is not even
> "guarded" by a keyword like "if" or "while" which can help as indicators
> that
1 - 100 of 731 matches
Mail list logo
