Personally, I dislike the presumption that you state in the bpo, that
typing and linters have changed things so that being a sequence is more
closely tied to implementing the Sequence abc these days. I consider it a
flaw in typing and linters if that’s the case, not something to embrace.
Paul.
PS
On Mon, 17 Jan 2022 at 06:52, Denis Kotov wrote:
> > And that's why you need to do more work than arguing that in principle
> > C++ is just a better language than C. We've been hearing that for 4
> > decades now (at least we greybeards have), and we've discovered that
> > for many existing applic
Strong -1 from me.
urllib.request may not be "best practice", but it's still extremely
useful for simple situations, and urllib.parse is useful for basic
handling of URLs.Yes, the more complex aspects of urllib are better
handled by external packages, but that's not sufficient argument for
removin
On Sun, 6 Feb 2022 at 14:15, Victor Stinner wrote:
> I propose to deprecate the urllib module in Python 3.11. It would emit
> a DeprecationWarning which warn users, so users should consider better
> alternatives like urllib3 or httpx: well known modules, better
> maintained, more secure, support H
On Sun, 6 Feb 2022 at 16:51, Christian Heimes wrote:
> The urllib package -- and to some degree also the http package -- are
> constant source of security bugs. The code is old and the parsers for
> HTTP and URLs don't handle edge cases well. Python core lacks a true
> maintainer of the code. To
On Sun, 27 Mar 2022 at 00:52, Ethan Furman wrote:
>
> [apologies for the late post, just found this in my drafts folder]
>
> On 2/7/22 12:49 AM, Stéfane Fermigier wrote:
>
> > 3. Overall, I think the days where "battery included" was a positive
> > argument are over
>
> I strongly disagree. Bein
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 JSON implementation, and find an
> absolutely astonishing number of options. I just did a search for "JSON"
> on PY
On Mon, 28 Mar 2022 at 17:45, Steve Dower wrote:
>
> I think to most people "batteries included" doesn't necessarily mean
> "standard library," with all that implies. It just means "it came with
> the first thing that I installed" (or alternatively, "at no additional
> charge").
I think that for
On Mon, 28 Mar 2022 at 20:37, Steve Dower wrote:
> Please let us know
> *publicly* if you want to become the maintainer for a stdlib module and
> then we can support them, but if nobody is willing/able/ready to care
> for them it's irresponsible for us to keep shipping them to users.
I'm sorry f
On Tue, 29 Mar 2022 at 00:37, Toshio Kuratomi wrote:
> One thing about talking about "make urllib more like requests" that is
> different than any of the other libs, though, is that requests aims to be
> easier to use than anything else (which I note Chris Barker called out as why
> he wanted
On Wed, 30 Mar 2022 at 12:28, Steve Dower wrote:
>
> On 30Mar2022 1132, Baptiste Carvello wrote:
> > Le 28/03/2022 à 18:44, Steve Dower a écrit :
> >> I think to most people "batteries included" doesn't necessarily mean
> >> "standard library," with all that implies. It just means "it came with
>
On Sat, 2 Apr 2022 at 02:30, Christopher Barker wrote:
>
> On Fri, Apr 1, 2022 at 4:06 AM Steve Dower wrote:
>>
>> The main difference is that 'immutables' offers you a stable/versioned
>> interface to use it, while the one that's in CPython is an internal
>> implementation detail. If one day we
On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer)
wrote:
> > I would welcome a multiline comment format that didn't involve docstrings.
>
> Err, sorry, I meant multiline string format.
I'm confused, what's wrong with """..."""? Triple quoted strings are
not exclusively for docstrings...
Pa
On Fri, 8 Apr 2022 at 09:29, Malthe wrote:
> A workflow definition which could be a 5-liner quickly
> becomes a 20-liner – consider for example:
>
> default_args = {
> "start_date": @datetime.datetime(...)
> }
Are you exaggerating for effect here or would this *actually* just exp
On Fri, 8 Apr 2022 at 10:27, Malthe wrote:
>
> On Fri, 8 Apr 2022 at 08:51, Paul Moore wrote:
> > Are you exaggerating for effect here or would this *actually* just expand to
> >
> > from datetime import datetime
> > default_args = {
> > "start_da
On Fri, 8 Apr 2022 at 12:57, Daniel Pope wrote:
>
> On Fri, 8 Apr 2022 at 12:23, Steve Dower wrote:
> >
> > I've read the rest of the thread so far, and agree strongly that we
> > can't do this at the language/runtime level.
>
> You mean the hoisting, right?
>
> I don't see any reason why an impo
On Sat, 23 Apr 2022 at 22:42, Rob Cliffe via Python-Dev
wrote:
>
> UGH!
>
> I thought there was a general understanding that when typing was added
> to Python, there would be no impact, or at least minimal impact, on
> people who didn't use it. (Raises hand.)
> Now we see an(other) instance of in
On Wed, 27 Apr 2022 at 15:32, Victor Stinner wrote:
>
> On Tue, Apr 26, 2022 at 11:46 AM Victor Stinner wrote:
> > I propose adding a -P option to Python command line interface to "not
> > add sys.path[0]":
> > https://github.com/python/cpython/pull/31542
>
> My plan is to merge this change at 20
On Wed, 27 Apr 2022 at 16:50, Victor Stinner wrote:
>
> Since I didn't get any serious review on my pull request since
> February, I created this thread on python-dev to get more people
> looking into this issue.
Pull requests don't get much visibility from the wider community - I
know I can't ke
On Tue, 10 May 2022 at 16:31, Barney Stratford
wrote:
>
> Hello all.
>
> It occurs to me that creating threads in Python is more awkward than it needs
> to be. Every time I want to start a new thread, I end up writing the same
> thing over and over again:
>
> def target(*args, **kwds):
> ...
On Fri, 13 May 2022 at 19:54, Brett Cannon wrote:
>
> Can we shut this down or unsubscribe the weekly email?
My understanding was that it would be updated to get its information
from Github once the transition was complete. Is that not going to
happen now? I'm not particularly bothered, as I only
On Mon, 17 Oct 2022 at 11:20, Denis Kotov wrote:
> Stephen J. Turnbull wrote:
> > Denis Kotov writes:
> > > See:
> > > https://youtube.com/clip/UgkxyNe_dsZKinT_RT3UGb-BaP0SnvKteo2o
> > > No thanks, if it's not text I'm not going to look at it. I don't have
> > time to watch videos with no explan
On Sat, 3 Dec 2022 at 10:57, Yoni Lavi wrote:
> There's a number of Core devs that have taken strong positions against
> this change, citing various reasons ranging from "the addition of a
> function that returns a constant will cause bloat in the interpreter /
> needs to be tested / etc" to "wha
On Sat, 3 Dec 2022 at 14:46, Yoni Lavi wrote:
> > I think this is over-complicating things. I think the key merit of your
> > original proposal was its simplicity. Proposing more complicated ways of
> > getting the result you want is (IMO) unlikely to succeed, and is only
> > likely to cause peop
On Wed, 2 Aug 2023 at 15:24, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Partly because that's where the other discussants are (the network
> externality is undeniably powerful), and partly (I believe) because
> effective use of email is a skill that requires effort to acqu
On Fri, 9 Aug 2019 at 17:55, Steve Dower wrote:
> > * change the SyntaxWarning into a default-silenced one that fires every
> > time a .pyc is loaded (this is the hard part, but it's doable)
> > * change pathlib.PureWindowsPath, os.fsencode and os.fsdecode to explicitly
> > warn when the path co
On Sat, 10 Aug 2019 at 00:36, Steven D'Aprano wrote:
> 2. To strongly discourage newbie Windows developers from hard-coding
> paths using backslashes, but to use forward slashes instead.
(Side issue)
As a Windows developer, who has seen far too many cases where use of
slashes in filenames implie
On Sat, 10 Aug 2019 at 12:06, Chris Angelico wrote:
>
> On Sat, Aug 10, 2019 at 6:39 PM Paul Moore wrote:
> > There are *many* valid ways to write Windows pathnames in your code:
> >
> > 1. Raw strings
> > 2. Doubling the backslashes
> > 3. Using pathlib
On Sun, 11 Aug 2019 at 03:37, Rob Cliffe via Python-Dev
wrote:
> Usually, but not always. I have not infrequently used files with a
> blank extension.
> I can't recall using a directory name with an extension (but I can't
> swear that I never have).
I've often seen directory names like "1. Overv
On Mon, 9 Sep 2019 at 06:28, Kyle Stanley wrote:
> Steve Dower wrote:
> > It also means that regular users can install packages without needing to be
> > admin, and without corrupting other user's installs.
>
> Does this have any advantage over using a virtual environment? I can imagine
> this m
On Wed, 18 Sep 2019 at 18:52, Chris Barker via Python-Dev
wrote:
> it would be good to be clear what EXACTLY "support stops" means.
Generally, when people ask questions like this, I struggle, because
it's not altogether clear to me what they think they mean in the first
place by the "support" tha
On Thu, 19 Sep 2019 at 17:34, Stephen J. Turnbull
wrote:
> > Generally, when people ask questions like this, I struggle,
>
> Yup. But I think the above is a good first cut.
Agreed, it's a great summary of what "support stops" means. What I was
trying to say was more that I'm not quite sure wher
On Fri, 25 Oct 2019 at 16:16, Freddy Rietdijk wrote:
>
> I think it is more important to have CI that clearly shows the impact of dev
> versions of the interpreter and core packages. Some of us in the Nixpkgs
> community had this idea for Python core packages as well (and potentially
> scientif
On Thu, 28 Nov 2019 at 15:35, Facundo Batista wrote:
>
> Hello!
>
> Did we take a decision of what comes after 3.9?
>
> Do we have a PEP for that decision? (couldn't find it)
>
> (not arguing in favor of one or another, just want to know the
> rationale behind it)
I don't think there's been a for
On Thu, 28 Nov 2019 at 15:55, Victor Stinner wrote:
>
> It has been discussed a few months ago. There is the "if six.PY3: ..."
> issue and similar issues which should be solved first. Basic example:
I've seen a few fixes to projects to remove assumptions that the "X"
in 3.X is a single digit. So
On Fri, 6 Dec 2019 at 09:33, Steven D'Aprano wrote:
>
> Although I am cautiously and tentatively in favour of setting limits
> if the benefits Mark suggests are correct, I have thought of at least
> one case where a million classes may not be enough.
>
> I've seen people write code like this:
>
>
On Sun, 8 Dec 2019 at 09:00, Nick Coghlan wrote:
>
> On Sat., 7 Dec. 2019, 2:08 am Victor Stinner, wrote:
>>
>> Le ven. 6 déc. 2019 à 16:00, Guido van Rossum a écrit :
>> > Let's try to avoid having PEP discussions in the peps tracker, period.
>> > That repo's tracker is only meant to handle ma
On Wed, 11 Dec 2019 at 11:38, Mark Shannon wrote:
> Your opinions without any justifications are welcome, but I need precision.
>
> For example, saying "I don't want any limits ever for anything" is
> precise, but saying "A limit of 1 million is OK provided the performance
> improvements justify i
On Tue, 17 Dec 2019 at 11:13, Larry Hastings wrote:
> I lack this strongly mathematical view of sets others have espoused; instead
> I view them more like "dicts without values". I'm therefore disgruntled by
> this inconsistency between what are I see as closely related data structures,
> and
On Thu, 9 Jan 2020 at 10:42, Michael wrote:
> Last year I was struggling to get some code to pass CI in pypa/packaging.
> There were other issues, but one that suprised me most was learning to ALWAYS
> use double quotes (") to get the code to pass the lint check (type checking).
> Anything usin
On Fri, 24 Jan 2020 at 02:36, Guido van Rossum wrote:
> I'm tempted to declare this implementation-defined behavior -- *implicit*
> calls to __eq__ and __ne__ *may* be skipped if both sides are the same object
> depending on the whim of the implementation.
This sounds reasonable to me. It coul
On Fri, 24 Jan 2020 at 08:54, Victor Stinner wrote:
>
> The change is that Python 2.7 is no longer supported (since 2020-01-01).
However the assertion here seems to be that some people are unprepared
for this (which seems to me like it's their problem, not ours).
Features getting deprecated in ne
On Fri, 24 Jan 2020 at 11:15, Terry Reedy wrote:
>
> On 1/24/2020 4:23 AM, Paul Moore wrote:
> > We could add an extra clause here: """As an optimisation, when the
> > implementation *implicitly* compares two values for equality (for
> > example, in list co
On Fri, 24 Jan 2020 at 14:14, Miro Hrončok wrote:
>
> On 24. 01. 20 14:02, Eric V. Smith wrote:
> > I think the concern is that with removing so many deprecated features, we're
> > effectively telling libraries that if they want to support 3.9, they'll have
> > stop supporting 2.7. And many librar
On Tue, 4 Feb 2020 at 22:10, Mike Miller wrote:
>
> On 2020-02-04 12:10, Brett Cannon wrote:
> > Please be careful making that claim. Over my 16 years of helping manage
> > this project I can tell you that claim is not universally true no matter
> > how small and simple you think something is.
>
On Thu, 6 Feb 2020 at 20:17, Mark Shannon wrote:
>
> I recently unintentionally changed the semantics of this expression
> `[print("a"), *None, print("b")]`.
> PEP 448 states that this should raise an exception, but does not specify
> evaluation order.
>
> My implementation was based on the genera
On Thu, 6 Feb 2020 at 23:14, Guido van Rossum wrote:
>
> How did we move from [*a,...] to print(*a,...)? They are quite different.
It was a good way to demonstrate evaluation order, as an expression
with a visible side effect. What the expression [print("a"), *None,
print("b")] prints before the
Sorry, ignore that - I see Serhiy used "print(*a)".
Paul
On Fri, 7 Feb 2020 at 08:10, Paul Moore wrote:
>
> On Thu, 6 Feb 2020 at 23:14, Guido van Rossum wrote:
> >
> > How did we move from [*a,...] to print(*a,...)? They are quite different.
>
> It was a
On Tue, 3 Mar 2020 at 19:31, Abdur-Rahmaan Janhangeer
wrote:
>
> Just for learning purposes, why was this improvement not included at the
> beginning? (I missed the original thread)
Mostly just a matter of caution. It's a lot easier to relax the
restrictions later than it is to add restrictions
On Wed, 25 Mar 2020 at 00:42, Dennis Sweeney
wrote:
>
> There were at least two comments suggesting keeping it to one affix at a time:
>
> https://mail.python.org/archives/list/python-dev@python.org/message/GPXSIDLKTI6WKH5EKJWZEG5KR4AQ6P3J/
>
> https://mail.python.org/archives/list/python-dev@pyth
On Thu, 2 Apr 2020 at 19:20, Guido van Rossum wrote:
>
> Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros
> Nikolaou and myself have been working on a new parser for CPython. We are now
> far enough along that we present a PEP we've written:
>
> https://www.python.org/de
On Mon, 13 Apr 2020 at 11:20, Steve Dower wrote:
>
> On 11Apr2020 1156, Rhodri James wrote:
> > On 10/04/2020 18:20, Victor Stinner wrote:
> >> Note: Cython and cffi should be preferred to write new C extensions.
> >> This PEP is about existing C extensions which cannot be rewritten with
> >> Cyth
On Wed, 15 Apr 2020 at 15:41, Brett Cannon wrote:
>
> The "hey I'm a dict, but look over hear and now you can treat my like like
> any other object" duality doesn't sit well with me. I do understand the idea
> of wanting to convert something to convert JSON data into a more object-like
> access
On Sat, 18 Apr 2020 at 00:03, Eric Snow wrote:
>
> On Fri, Apr 17, 2020 at 2:59 PM Nathaniel Smith wrote:
> > I know you want folks to consider PEP 554 on its own merits, ignoring
> > the GIL-splitting work, but let's be realistic: purely as a
> > concurrency framework, there's at least a dozen
On Tue, 21 Apr 2020 at 15:31, Eric Snow wrote:
> Here are the options for handling non-compliant extension modules:
>
> 1. do nothing (extensions may break in ways that are hard for users to
> deal with)
> 2. raise ImportError if an extension without PEP 489 support is
> imported in a subinterpret
On Mon, 27 Apr 2020 at 16:21, Miro Hrončok wrote:
>
> On 23. 04. 20 21:36, Sumana Harihareswara wrote:
> > We would be grateful for all the testing that users could do to ensure
> > that, when pip 20.1 is released, it's as solid as we can make it.
>
> We are doing some basic testing in Fedora.
>
On Wed, 29 Apr 2020 at 02:26, Eric Snow wrote:
> Subinterpreters run all Python code right now. I'm guessing by
> "general python code" you are talking about the code folks are writing
> plus their dependencies. In that case, it's only with extension
> modules that we run into a problem, and we
On Mon, 4 May 2020 at 19:19, Eric Snow wrote:
>
> On Mon, May 4, 2020 at 11:30 AM Eric Snow wrote:
> > Further feedback is welcome, though I feel like the PR is ready (or
> > very close to ready) for pronouncement. Thanks again to all.
>
> oops
>
> s/the PR is ready/the PEP is ready/
One thing
On Thu, 7 May 2020 at 01:34, Cameron Simpson wrote:
> Maybe I'm missing something, but the example that comes to my mind is
> embedding a Python interpreter in an existing nonPython programme.
>
> My pet one-day-in-the-future example is mutt, whose macro language is...
> crude. And mutt is singl
On Tue, 12 May 2020 at 07:53, Brandt Bucher wrote:
> > > However, zip_longest is really another beast entirely
> > No, it isn't.
>
> It has a completely independent implementation, a different interface, lives
> in a separate namespace, and doesn't even reference zip in its documentation.
> So
On Fri, 15 May 2020 at 07:10, Brandt Bucher wrote:
>
> This whole sub-thread of discussion has left me very confused. Was anything
> unclear in the PEP's phrasing here? If so, I'd like to improve it. The
> original quote is: "The goal here is not just to provide a way to catch bugs,
> but to al
On Fri, 15 May 2020 at 16:01, David Mertz wrote:
>
> I'm a little frustrated by the tone in which the PEP dismisses the option
> that is most supported in the discussion. It fine for Brandt to have a
> different preference himself, but I think it ought to be presented more
> neutrally.
Agreed.
[Cut the previous votes because someone's quoting didn't survive my
email client and I can't be bothered fixing it]
If everyone else is doing it...
itertools.zip_strict() +1
zip(strict=True) -0
zip.strict() -0.5
zip(mode='strict') -1
Paul
___
Python-De
On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote:
> Starting a new process is cheap. On my machine, starting a new Python
> process takes under 1ms and uses a few Mbytes.
Is that on Windows or Unix? Traditionally, process creation has been
costly on Windows, which is why threads, and in-process s
On Wed, 17 Jun 2020 at 12:27, Victor Stinner wrote:
> > If PEP 387 (Backwards Compatibility Policy) is accepted, all the
> > incompatible changes changes will require a two-year deprecation period.
> > Right?
>
[...]
>
> So far, it doesn't seem to be a giant disaster :-) Only a few C
> extensions
On Tue, 23 Jun 2020 at 17:07, Guido van Rossum wrote:
>
> I'm happy to present a new PEP for the python-dev community to review. This
> is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin.
>
> Many people have thought about extending Python with a form of pattern
> matching
On Wed, 24 Jun 2020 at 07:40, Ethan Furman wrote:
> Second premise: there is no practical difference between
>
> match color:
> case BLACK:
> # do stuff
>
> and
>
> match color:
> case _:
> BLACK = color
> # do stuff
You've alrea
On Wed, 24 Jun 2020 at 11:44, Greg Ewing wrote:
> Another possibility would to be allow cases to share the same
> suite by stacking them:
>
> case 401:
> case 402:
> case 403:
>...
I feel as though this could be useful (although I don't have a
specific use case in mind). The o
On Wed, 24 Jun 2020 at 19:49, M.-A. Lemburg wrote:
> match something:
> case 0 | 1 | 2 | _:
> print("Small number or something else")
> case [] | [_]:
> print("A short sequence")
> case _:
> print("Not sure what this is")
> case str() | bytes():
> p
On Fri, 26 Jun 2020 at 02:42, Raymond Hettinger
wrote:
>
> > it is hard to make a decision between the pros and cons,
> > when the pros are in a single formal document and the
> > cons are scattered across the internet.
>
> Mark, I support your idea. It is natural for PEP authors to not fully
>
On Fri, 26 Jun 2020 at 03:37, Gregory P. Smith wrote:
>
> Litmus test: Give someone who does not know Python this code example from the
> PEP and ask them what it does and why it does what it does:
>
> match get_shape():
> case Line(start := Point(x, y), end) if start == end:
> print(
On Fri, 26 Jun 2020 at 11:29, Daniel Moisset wrote:
>
> I think roughly half of the uses will actually be for "the switch statement
> we never had", where all branches would be constants. I've been writing a lot
> of code like that these last couple of weeks, so I may be biased (although
> the
Latin-1 is the encoding that maps every byte (0-255) to the Unicode
character with the same number. So it's special in that sense, and it
gets used when mapping 8-bit bytes via Unicode "without encoding".
Excuse my imprecise language here, I don't know the correct Unicode
terms without going & look
On Thu, 2 Jul 2020 at 14:34, Henk-Jaap Wagenaar
wrote:
> PEP-8 however does not mention a particular edition and the version that is
> readily available (in the public domain) does contain this problematic
> section "to use the masculine pronouns whenever possible" which is not
> inclusive.
(
On Thu, 2 Jul 2020 at 16:53, David Mertz wrote:
>
> On Thu, Jul 2, 2020, 11:08 AM Piper Thunstrom
>>
>> Paul, this is actually a good question to ask. In general, singular "they"
>> is becoming more popular. It's already used frequently for the singular
>> indeterminate pronoun:
>
> The first at
On Thu, 2 Jul 2020 at 21:18, David Antonini wrote:
>
> No contention to the contrary, but as a routine, post-merge git history
> rewrite, not a grand plan, from what I understand.
David,
When you post, you (or more likely your mail program) somehow adds the
name of the author of the post that yo
On Sat, 4 Jul 2020 at 17:48, MRAB wrote:
>
> On 2020-07-04 05:51, Greg Ewing wrote:
> > On 4/07/20 4:33 am, Jim J. Jewett wrote:
> >> If Bob and Alice seem neutral to you, would you do a double-take on
> >> Kehinde or Oladotun?
> >
> > Maybe we should use randomly generated names for hypothetical
On Tue, 7 Jul 2020 at 15:40, Henk-Jaap Wagenaar
wrote:
>
> On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev
> wrote:
>>
>> I don't like the .name syntax (grit on Tim's monitor; does not
>> suggest the meaning). [...] But I don't know what syntax (where necessary)
>> to suggest.
>
>
>
On Tue, 7 Jul 2020 at 18:35, Guido van Rossum wrote:
>
> On Tue, Jul 7, 2020 at 9:09 AM Paul Moore wrote:
>>
>> Hopefully the PEP authors intend to post an updated version
>> (preferably with a summary of changes, for people struggling to keep
>> up with th
On Fri, 10 Jul 2020 at 12:08, Greg Ewing wrote:
>
> A thought about the indentation level of a speculated "else" clause...
>
> Some people have argued that "else" should be at the outer level,
> because that's the way it is in all the existing compound statements.
>
> However, in those statements,
On Sat, 11 Jul 2020 at 14:39, Ethan Furman wrote:
>
> On 07/11/2020 04:20 AM, Paul Sokolovsky wrote:
>
> > Actually, the whole argument in PEP 622 regarding "else:", that its
> > placement is ambiguous sounds like a rather artificial write-off.
> > Individual "case"'s are aligned together, but sud
On Sun, 12 Jul 2020 at 10:47, Larry Hastings wrote:
> In that case, I'd like to make a specific pitch for "don't make '_' special".
> (I'm going to spell it '_' as it seems to be easier to read this way; ignore
> the quotes.)
Overall, this sounds mostly reasonable. I'm cutting nearly everythin
On Fri, 4 Sep 2020 at 16:53, Fred Drake wrote:
>
> On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote:
> > While I agree with the general suggestion of deprecating distutils as a
> > publicly-visible module (in favour of encouraging users to rely on
> > setuptools), it seems to me that the argu
The performance figures in the Python 3.9 "What's New" (here -
https://docs.python.org/3/whatsnew/3.9.html#optimizations) did look
oddly like a lot of things went slower, to me. I assumed I'd misread
the figures, and moved on, but maybe I was wrong to do so...
Paul
On Wed, 14 Oct 2020 at 14:17, P
On Thu, 15 Oct 2020 at 16:31, Erlend Aasland wrote:
>
> Actually both sqlite3.version and sqlite3.version_info, the former as a
> string, the latter as a tuple.
However, sqlite3.sqlite_version and sqlite3.sqlite_version_info should
definitely be retained, as they give the version of the sqlite l
2009/2/16 Daniel (ajax) Diniz :
> Hi,
> Here's a summary of what's been accomplished and what's almost done.
> This kinda marks the end of this Bug Season for me, but I'd like to do
> at least one more installment before PyCon.
Can I, for one, offer a *huge* round of applause for what you've
achie
2009/2/21 Stephen J. Turnbull :
> Besides, if Barry makes this experiment *now* and enough people speak
> up that it will make it difficult for them to contribute to Python,
> the Bazaar proponents can revert to an older version of Bazaar before
> a final decision is made.
In addition, I think it'
2009/2/21 "Martin v. Löwis" :
>> Wouldn't such hypothetical core Python developers be able to build and
>> run their own local copy of bzr, using that self-compiled Python?
>
> It has been hypothetical for a while, but it never was about core
> developers.
Given that it *is* all hypothetical by no
2009/2/21 Barry Warsaw :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 21, 2009, at 4:11 PM, Paul Moore wrote:
>
>> PS Just for my own information, am I correct in thinking that it is
>> *only* Bazaar in the (D)VCS world that has this problem, to any
2009/2/25 Sudhir Kakumanu :
> Hi all,
> I am new to Python, i have installed python 2.5.4 and it is my requirement.
> I need to retrieve the path of filename in python.
This list is for the developers of Python to discuss future changes to
the language and its implementation. It is not the correct
2009/2/27 Benjamin Peterson :
> 2009/2/27 Nick Coghlan schrieb:
>>
>> I should have a PEP (and implementation) ready for alpha 2 to address
>> the current discrepancy between contextlib.nested and actual nested with
>> statements:
>> http://bugs.python.org/issue5251
>>
>> If you do add a reference
2009/3/2 Benjamin Peterson :
> 2009/3/1 Paul Moore :
>>
>> Is it worth getting simplegeneric exposed in 3.1
>> (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd
>> like to see it hit 3.1. The patch is against trunk (for 2.7) at the
>>
2009/3/1 Nick Coghlan :
> As much as I'd like to get a simple generic implementation into
> functools, the lack of support for ABCs still bothers me (despite my
> last post about that on the tracker item). I'd be a -0 on it going in as
> is, but if someone can figure out a clever way of supporting
2009/3/2 P.J. Eby :
> By the way guys, are you aware of:
>
> http://pypi.python.org/pypi/simplegeneric
Yes. It has been mentioned, and I am certainly aware of both it and
RuleDispatch.
> There might be a bit of name confusion by exposing pkgutils' internal
> simplegeneric there. Perhaps it shou
2009/3/2 Jeffrey Yasskin :
> I tend to think it's a bug in ABCs. You seem to have thought of
> several possible ways to fix it, and I don't have strong preferences
> between them.
I've discussed ways of fixing simplegeneric, but not of fixing the
issue with ABCs. I'm not sure the ABC "issue" is fi
2009/3/3 Jeffrey Yasskin :
> Unfortunately, I think overloading functions on Number or Iterable
> would be really useful, and constraining it to only look at base
> classes would be unfortunate.
That could well be the case. So the question is, I guess, how would
you write such a function now? Beca
2009/3/4 Guido van Rossum :
> On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan wrote:
>> Benjamin Peterson wrote:
>>> Yes, I'm already looking forward to Py4k now. :)
>>
>> Shh, Guido will need at least 5 years before he's ready to contemplate
>> going through something like this again.
>>
>> Or maybe
2009/3/11 Greg Ewing :
> Lie Ryan wrote:
>
>> I actually prefer strings. Just like 'w' or 'r' in open().
>>
>> Or why not add "f" "c" as modes?
>>
>> open('file.txt', 'wf')
>
> I like this, because it doesn't expand the signature that
> file-like objects need to support. If you're wrapping
> anothe
2009/3/13 Chris Withers :
> If a decent package management system *was* included, this wouldn't be an
> issue..
Remember that a "decent package management system" needs to handle
filling in all the forms and arranging approvals to get authorisation
for packages when you download them.
And no, I'm
2009/3/13 Tres Seaver :
> Paul Moore wrote:
>> 2009/3/13 Chris Withers :
>>> If a decent package management system *was* included, this wouldn't be an
>>> issue..
>>
>> Remember that a "decent package management system" needs to handle
>
901 - 1000 of 1862 matches
Mail list logo
