[Python-Dev] Re: Rejecting PEP 606 and 608

Victor Stinner wrote: > Le ven. 6 déc. 2019 à 16:00, Guido van Rossum gu...@python.org a écrit : > > Let's try to avoid having PEP discussions in the peps > > tracker, period. That repo's tracker is only meant to handle markup and > > grammar. > > I recall that some PEPs have been discussed in len

[Python-Dev] Re: Travis CI for backports not working.

Victor Stinner wrote: > In that case, would you mind to make Travis CI mandatory again? Done! > Victor > Le ven. 6 déc. 2019 à 19:10, Brett Cannon br...@python.org a écrit : > > > > Victor Stinner wrote: > > Hello, > > Le mar. 26 nov. 2019 à 20:40, Brett Cannon

[Python-Dev] Re: [python-committers] [RELEASE] Python 3.8.1rc1 is now available for testing

Jason R. Coombs wrote: > I think I missed the announcement of the cutoff date for 3.8.1; I was hoping > to get > some bug fixes in for > importlib.metadata.https://github.com/python/cpython/pull/17568 > These aren’t crucial bugfixes, but it would be nice not to have them linger > for months. Ju

[Python-Dev] Re: Travis CI for backports not working.

This is failing again, so I had to switch off Travis from being a requirement (again). I'm not not going to flip it back on until Travis has been stable for a month as I don't like being the blocker on stuff when I can help it. And if Travis isn't stable in a month then we might need to start t

[Python-Dev] Re: Travis CI for backports not working.

Steve Dower wrote: > On 13Dec2019 0233, Victor Stinner wrote: > > Azure Pipelines were very unstable one year ago. It's > > getting better, > > but there are still some random bugs sometimes. They are not really > > blocking, so I didn't report them. > > The only ones I'm aware of are macOS builds

[Python-Dev] Re: Adding a toml module to the standard lib?

Specifically the work to reach 1.0 is tracked in https://github.com/toml-lang/toml/projects/1 and I too think we should wait until 1.0 comes out for the exact reasons Victor laid out. I will also mention that https://github.com/pradyunsg who is a core dev of pip and very active PyPA member is o

[Python-Dev] Re: Python Documentation and AIX specifics - how to proceed?

That whole directory is mostly outdated (e.g. those Wing files are two major versions behind and we have ripped out all other editor-specific files in the repo). I think the first question is what do we want for that directory to be? Based on that we can decide if something like AIX build instru

[Python-Dev] Re: Should set objects maintain insertion order too?

The only `OrderedSet` use I have seen in the wild is https://github.com/python-hyper/uritemplate/search?q=orderedset&unscoped_q=orderedset . ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Two pieces of feedback on this. One, nose is a bad example because that project has been telling people for years to switch to nose2 so the fact that people have still not switched something that should mostly be a direct swap after years of being asked to does not motivate in wanting to postpon

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

Terry Reedy wrote: > On 1/24/2020 4:23 AM, Paul Moore wrote: > > On Fri, 24 Jan 2020 at 02:36, Guido van Rossum gu...@python.org 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 dep

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Victor Stinner wrote: > Le jeu. 23 janv. 2020 à 20:45, Brett Cannon br...@python.org a écrit : > > Two pieces of feedback on this. One, nose is a bad > > example because that project has been telling people for years to switch to > > nose2 so the > > fact that peo

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Eric V. Smith wrote: > On 1/24/2020 9:14 AM, 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

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Matthias Bussonnier wrote: > Is it possible to change some of those deprecation from Warn-by-default (but > can add a > warning filter to make them error) to error-by-default (but can add a filter > to make them > only warnings). Yes, although it would be a change to how Python functions. Basica

[Python-Dev] Re: Merge bugs.python.org accounts

Victor Stinner wrote: > You may open a ticket at > https://github.com/python/bugs.python.org/issues > but I'm not sure who > is in charge of bugs.python.org, nor how to merge two accounts. Or if it's even doable short of direct database manipulation; I'm not aware of Roundup providing such functi

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Ethan Furman wrote: > On 2020-01-23 07:20, Victor Stinner wrote: > > Python 3.9 introduces many small incompatible changes > > which broke tons > > On 2020-01-31 19:47, Mike Miller wrote: > > There's a well-known and established way of signaling > > breaking changes in software platforms—it is to i

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Mike Miller wrote: > On 2020-02-03 17:00, Brett Cannon wrote: > > Until you're being asked to maintain all of that for > > a decade. We paid a major price keeping Python 2 alive for over a decade. > > Now I'm not > > saying it wasn't the right thing

[Python-Dev] Re: PEP 584: Add Union Operators To dict

I agree that if we want to go down the road of creating a copy to allow for subclasses then we should define a dunder method for such a use, even if it's redundant in the face of dict.copy(). ___ Python-Dev mailing list -- python-dev@python.org To unsub

[Python-Dev] Re: Clarification of unpacking semantics.

I agree that if this is only in 3.9 then this is a cleanup of semantics that were a bit off and should stay but get a mention in What's New. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] Re: Merging PRs without CLA signed

My personal stance is if Microsoft Word could have come up with the change then a signed CLA is _probably_ not needed (IOW typos and grammatical errors). But honestly, I fall into the same camp as Mariatta and Pablo out of laziness and fear of being wrong. :) Laziness because there are plenty of

[Python-Dev] New discuss.python.org category: Core Dev

I just created https://discuss.python.org/c/core-dev/ to somewhat mirror this mailing list as people were asking for an equivalent space on discuss.python.org due to the Users category now being heavily used for user questions (which makes sense based on the title 😄). I also moved the SC Nomina

[Python-Dev] Re: New discuss.python.org category: Core Dev

ory" topic, but I suspect that the name "Core > Development" would make the purpose of the category more immediately clear. > On Tue, Mar 3, 2020 at 7:09 PM Brett Cannon br...@python.org wrote: > > I just created https://discuss.python.org/c/core-dev/ > > to somewhat

[Python-Dev] VS Code extension for Python.asdl

https://marketplace.visualstudio.com/items?itemName=brettcannon.zephyr-asdl Basically syntax highlighting and automatic bracket matching for those that ever have to work with Python.asdl. If the number of direct installs of this extension breaks into double digits I will be a bit shocked. ;) ___

[Python-Dev] Re: VS Code extension for Python.asdl

the only thing that would require a lot of coding), but as with most things it requires having the time to do it. :) > On Tue, Mar 3, 2020 at 6:44 PM Brett Cannon br...@python.org wrote: > > https://marketplace.visualstudio.com/items?itemName=brettcannon.zephyr-asdl > > Basically

[Python-Dev] Re: pathlib.Path: inconsistent symlink_to() and link_to()

Antoine Pitrou wrote: > On Wed, 11 Mar 2020 11:17:22 + > Barney Gale barney.g...@gmail.com wrote: > > Hi, > > Pathlib's symlink_to() and link_to() methods have different argument > > orders, so: > > a.symlink_to(b) # Creates a symlink from A to B > > a.link_to(b) # Creates a hard link from B

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

-1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the same reasons as "trim*". And if no consensus is reached in this thread for a name I would assume the SC is going to ultimately

[Python-Dev] REMINDER: report conduct issues to the Conduct WG

The steering council wants to remind folks that if you have witnessed or experienced any conduct that you think may go against the PSF Code of Conduct to please report those incidents to cond...@python.org. This includes reporting micro-aggressions like feeling dismissed so that any pattern of such

[Python-Dev] Re: PEP 617: New PEG parser for CPython

Greg Ewing wrote: > On 3/04/20 7:10 am, 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:/

[Python-Dev] Re: Providing fix for modulefinder.py regression on Windows

Barry Scott wrote: > > On 12 Apr 2020, at 21:49, Eric V. Smith e...@trueblade.com wrote: > > On 4/12/2020 4:08 PM, Barry Scott wrote: > > On 11 Apr > > 2020, at 16:28, Barry Scott > mailto:ba...@barrys-emacs.org> wrote: > > modulefinder.py does not open source files in "rb" which > > prevents comp

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

It seems a little odd to be dictating website updates about other VMs in this PEP. I'm not arguing that we shouldn't update the site, I just think requiring it as part of this PEP seems tangential to what the PEP is focusing on. ___ Python-Dev mailing l

[Python-Dev] Re: Improvement to SimpleNamespace

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 pattern, though. So if something were to be brought in, for

[Python-Dev] Re: Improvement to SimpleNamespace

I will also say that when I do want such a shift from JSON or dict data structures to a more concrete one I write my own classmethod to provide some error checking, so I haven't personally needed a package to do this for me. ___ Python-Dev mailing list

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

Eric Snow wrote: > Hi all, > It was nice to speak with many of you at the online language summit > this week. It was the next best thing to seeing you all in person! :) > With the 3.9 feature freeze coming up I'm considering options for PEP > > I'm hopeful to have a pronouncement from Antoine in

[Python-Dev] Accepting PEP 617: New PEG parser for CPython

The steering council is happy to announce that we have accepted PEP 617! Thanks to the PEP authors for all their hard work (which includes sending a PR to update the acceptance of the PEP 😉). ___ Python-Dev mailing list -- python-dev@python.org To unsu

[Python-Dev] Re: Adding a "call_once" decorator to functools

Victor Stinner wrote: > Hi, > A pattern that I used multiple times is to compute an object attribute > only once and cache the result into the object. Dummy example: How is that different from https://docs.python.org/3/library/functools.html?highlight=cached_property#functools.cached_property? -

[Python-Dev] Re: For-If syntax

Questions like this are best asked on python-ideas. Specifically, though, you can get the same result with: for x in (n for n in y if n.is_some_thing): without requiring new syntax. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe

[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround

Just to be clear, this is executing the **same** workload in parallel, **not** trying to parallelize factorial. E.g. the 8 CPU calculation is calculating 50,000! 8 separate times and not calculating 50,000! once by spreading the work across 8 CPUs. This measurement is still showing parallel work

[Python-Dev] Re: Issues with import_fresh_module

I'm drowning in work this month, so if you need me to look at something then I unfortunately need a point-blank link of what you want me to look at with a targeted question. As for import_fresh_module() not being robust: of course it isn't because it's mucking with import stuff in a very non-st

[Python-Dev] Re: Issues with import_fresh_module

Maybe an initialization/import side-effect bug which is triggered if the module is imported twice? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/pyt

[Python-Dev] Re: Repr: where to place the address and additional info?

Serhiy Storchaka wrote: > The default repr of Python object is formatted using the following pattern: > <{typename} object at {address:#x}> > > And many custom reprs use similar patterns, but add some additional type > specific information. The type name first, followed by details and > address

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

Eric V. Smith wrote: > On 6/10/2020 8:33 AM, Mark Shannon wrote: > > Hi Petr, > > On 09/06/2020 2:24 pm, Petr Viktorin wrote: > > On 2020-06-05 16:32, Mark Shannon wrote: > > Whether Python interpreters run sequentially or in parallel, having > > them work will enable a use case I would like to se

[Python-Dev] PEP 387: backwards compatibility policy

Started at a discussion at https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 to try to finally resolve this PEP and our backwards compatibility policy. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email

[Python-Dev] Re: When can we remove wchar_t* cache from string?

Inada Naoki wrote: > On Tue, Jun 16, 2020 at 9:30 PM Victor Stinner vstin...@python.org wrote: > > > > Le mar. 16 juin 2020 à 10:42, Inada Naoki songofaca...@gmail.com a écrit : > > Hmm, Is there any chance to add > > DeprecationWarning in Python 3.9? > > In my experience, more and more projects a

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

I wanted to let people know that the four of us on the SC not driving this work -- i.e. everyone but Victor -- talked about this at our last meeting and we support the work to isolate interpreter state from being global. There are benefits for the situation where you have to integrate CPython wi

[Python-Dev] Re: PEP 622: Structural Pattern Matching

I will say that trying to follow https://github.com/python/peps/blob/master/pep-0622.rst#runtime-specification was really hard. Any chance of getting some pseudo-code that shows how a match is performed? Otherwise all of that wording tries so hard to be a spec that I found it hard to follow in

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Tue, Jun 23, 2020 at 5:08 PM Guido van Rossum wrote: > [SNIP] > On Tue, Jun 23, 2020 at 12:11 PM Brett Cannon wrote: > >> I will say that trying to follow >> https://github.com/python/peps/blob/master/pep-0622.rst#runtime-specification >> was really hard. Any ch

[Python-Dev] Re: The Anti-PEP

On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou wrote: > On Thu, 25 Jun 2020 11:57:49 +0100 > Mark Shannon wrote: > > > > An Anti-PEP is a way to ensure that those opposed to a PEP can be heard > > and, if possible, have a coherent voice. > > Hopefully, it would also make things a lot less stress

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Thu, Jun 25, 2020 at 3:17 AM Greg Ewing wrote: > On 25/06/20 7:50 pm, Anders Munch wrote: > > Pascal is a precedent for this placement of 'case', > > Yes, but it doesn't use it with "match". In fact it doesn't have > any keyword in front of the values to be matched; it goes like > > case n

[Python-Dev] Re: The Anti-PEP

On Thu, Jun 25, 2020 at 7:29 PM Gregory P. Smith wrote: > > On Thu, Jun 25, 2020 at 6:49 PM Raymond Hettinger < > raymond.hettin...@gmail.com> 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

[Python-Dev] Re: The Anti-PEP

On Thu, Jun 25, 2020 at 1:37 PM Chris Jerdonek wrote: > On Thu, Jun 25, 2020 at 11:52 AM Brett Cannon wrote: > >> On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou >> wrote: >> >>> I don't think this really works. A PEP has to present a consistent >>

[Python-Dev] Please refrain from posting on the PEP 8 threads for 24 hours

Regardless of what side you fall on, I think we can agree that emotions are running very high at the moment. Nothing is going to change in at least the next 24 hours, so I am personally asking folks to step back for at least that long and think about: 1. Is what you want to say going to contrib

[Python-Dev] Re: Flexible assignment targets

It's off the table from the perspective of PEP 622 and its authors. If you want to write a competing PEP that proposes your idea that's totally fine. On Wed, Jul 1, 2020 at 8:17 PM Elliott Chen wrote: > I don't think my proposal should be off the table for scope reasons > because it requires the

[Python-Dev] Re: Stable ABI question.

On Thu, Jul 2, 2020 at 8:05 PM Inada Naoki wrote: > On Thu, Jul 2, 2020 at 7:28 PM Victor Stinner wrote: > > > > Hi, > > > > Last time I looked at PyEval_AcquireLock(), it was used in the wild, > > but I don't recall exactly where, sorry :-( Before removing the > > functions, I suggest to first

[Python-Dev] Re: PEP 622 railroaded through?

On Fri, Jul 3, 2020 at 7:39 AM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > Whoa! > > I have an uneasy feeling about this PEP. > > AFAIK the usual procedure for adding a new feature to Python is: > An idea is raised and attracts some support. > Someone sufficiently motivat

[Python-Dev] Re: PEP 387: backwards compatibility policy

The SC has chosen to accept PEP 387! https://www.python.org/dev/peps/pep-0387/ On Fri, Jun 12, 2020 at 2:44 PM Brett Cannon wrote: > Started at a discussion at > https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 > to try to finally resolve this PEP and our

[Python-Dev] Re: Function suggestion: itertools.one()

For ideas like this it is best to discuss them on python-ideas. I'll also mention that this idea has been brought up at least twice before: search for threads about itertools and single() or first() (if I remember correctly). On Mon, Jul 27, 2020 at 12:07 PM Noam Yorav-Raphael wrote: > Hi, > >

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Thu, Aug 6, 2020 at 3:46 AM Mark Shannon wrote: > Hi Barry, > > How long do we have to present objections to PEP 622? > We haven't discussed a timeline among ourselves yet (unless it was discussed at the last meeting which missed 😁). > > I don't feel that the PEP gives adequate prominence t

[Python-Dev] **= does not follow the data model

If you read the language reference for augmented arithmetic assignment, you will note that it essentially says, "call __i__, and if that doesn't work call as if you were doing a b". Unfortunately it appears **= does not follow the rule of falling back on the binary arithmetic expression semantics.

[Python-Dev] Re: **= does not follow the data model

On Sun, Aug 23, 2020 at 1:57 PM Guido van Rossum wrote: > On Sun, Aug 23, 2020 at 1:09 PM Brett Cannon wrote: > >> If you read the language reference for augmented arithmetic assignment, >> you will note that it essentially says, "call __i__, and if that >> doe

[Python-Dev] Re: Resurrecting PEP-472

On Thu, Aug 27, 2020 at 7:13 AM Eric V. Smith wrote: > Leaving out the complication of needing a new sponsor, I would think the > best course of action would be to create a new PEP. I think keeping the > original rejected PEP is a net positive, and especially so if one of the > original authors i

[Python-Dev] Re: PEP 632: Deprecate distutils module

On Tue, Sep 8, 2020 at 2:27 AM Steve Dower wrote: > On 07Sep2020 1602, Stefan Krah wrote: > > I'm under the impression that distutils has effectively been frozen for > > the last decade, except for the substantial improvements you made for the > > MSVC part. > > > > For Unix, no one has addressed

[Python-Dev] Re: PEP 632: Deprecate distutils module

On Fri, Sep 11, 2020 at 4:25 AM Matthias Klose wrote: > On 9/4/20 1:28 PM, Steve Dower wrote: > > Hi all. > > > > setuptools has recently adopted the entire codebase of the distutils > module, so > > that they will be able to make improvements directly without having to > rely on > > patching the

[Python-Dev] Re: docs: I'd like new features to references their PEPs

I would honestly argue that if the language spec doesn't clearly explain the motivation behind something then that should be directly addressed rather than link back to the PEP. We already have an issue with people misinterpreting the PEPs as documentation, trying to keep them up-to-date, etc. and

[Python-Dev] Why do binary arithmetic operators care about differing method implementations but rich comparisons don't?

When you do a binary arithmetic operation, one of the things that dictates whether the left-hand side's __*__ method is called before the right-hand side's __r*__ method is if the left-hand side's __r*__ differs (there's also the fact __r*__ methods are not called if. the types are the same). Presu

[Python-Dev] Re: Why do binary arithmetic operators care about differing method implementations but rich comparisons don't?

inverse operation on the right-hand side object would break something. Would abuse of the syntax make a difference (e.g. making `>` do something magical)? -Brett > > On Sun, Sep 27, 2020 at 1:41 PM Brett Cannon wrote: > >> When you do a binary arithmetic operation, one of the

[Python-Dev] Re: Why do binary arithmetic operators care about differing method implementations but rich comparisons don't?

On Sun, Sep 27, 2020 at 9:56 PM Guido van Rossum wrote: > On Sun, Sep 27, 2020 at 5:58 PM Brett Cannon wrote: > >> >> >> On Sun, Sep 27, 2020 at 2:58 PM Guido van Rossum >> wrote: >> >>> Hm... IIRC the reason why we did this for `__r*__` is bec

[Python-Dev] Re: Why do binary arithmetic operators care about differing method implementations but rich comparisons don't?

Thanks for the explanation! And I will look at updating my blog post. On Mon, Sep 28, 2020 at 9:14 PM Guido van Rossum wrote: > On Mon, Sep 28, 2020 at 12:03 PM Brett Cannon wrote: > >> And the code that makes this happen is (I think) >> https://github.com/p

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

On Sun, Oct 4, 2020 at 1:24 AM Serhiy Storchaka wrote: > 04.10.20 01:06, Guido van Rossum пише: > > On Sat, Oct 3, 2020 at 9:28 AM Serhiy Storchaka > > wrote: > > The code of object.__dir__() is very old, it predates new-style > classes, > > and currently it g

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On Fri, Oct 9, 2020 at 7:23 AM Charalampos Stratakis wrote: > > > - Original Message - > > From: "Antoine Pitrou" > > To: python-dev@python.org > > Sent: Friday, October 9, 2020 4:02:51 PM > > Subject: [Python-Dev] Re: [python-committers] Resignation from Stefan > Krah > > > > > > Le 09/

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On Fri, Oct 9, 2020 at 5:34 AM Christian Heimes wrote: > On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote: > > I don't see the point of requiring to "write an apology", especially > > *before a 12-month ban*. If they understand that their behavior is > > wrong, there's no need for a ban, at

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On Fri, Oct 9, 2020 at 12:05 PM David Mertz wrote: > On Fri, Oct 9, 2020 at 10:25 AM Charalampos Stratakis > wrote: > >> Does it really matter that much in regards to the specific context? If >> someone poses problematic behavior (as it seems, as I'm not familiar with >> any specifics here), mai

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On Fri, Oct 9, 2020 at 2:55 PM Toshio Kuratomi wrote: > > > On Fri, Oct 9, 2020, 5:30 AM Christian Heimes > wrote: > >> On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote: >> > I don't see the point of requiring to "write an apology", especially >> > *before a 12-month ban*. If they understa

[Python-Dev] Re: Shutting down Import-SIG mailing list?

Shut it down! 😉 On Tue, Oct 13, 2020 at 9:46 AM Barry Warsaw wrote: > Seems fine to me. It’s an easy process; just ask postmaster@ and they > can shut the list down, retaining the archives read-only for posterity. > > -Barry > > > On Oct 13, 2020, at 09:26, Eric V. Smith wrote: > > > > Would a

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

I think if the project is not maintained externally and thus synced into the stdlib we can drop the attributes. On Wed, Oct 14, 2020 at 8:44 AM Guido van Rossum wrote: > None of these have seen much adoption, so I think we can lose them without > dire consequences. The info should be moved into

[Python-Dev] Re: Changing Python's string search algorithms

On Wed., Oct. 14, 2020, 17:37 Tim Peters, wrote: > [Steven D'Aprano ] > > Perhaps this is a silly suggestion, but could we offer this as an > > external function in the stdlib rather than a string method? > > > > Leave it up to the user to decide whether or not their data best suits > > the find

Re: [Python-Dev] Tracker archeology

On Tue, Feb 10, 2009 at 05:23, Daniel (ajax) Diniz wrote: > Hi all, > > For the past two days I've been doing some housekeeping > *cough*spamming*cough* on the tracker, mostly on ancient and/or easy > bugs. So far, ten bugs have been closed (thanks Antoine, Barry, > Benjamin, Guilherme, Martin an

Re: [Python-Dev] Tracker archeology

On Tue, Feb 10, 2009 at 05:23, Daniel (ajax) Diniz wrote: > [SNIP] > Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real > work and people agree the workflow would be better, I'd like to have > developer rights in the tracker, as per Antoine's suggestion. FWIW, I > have no proble

Re: [Python-Dev] Python-acceleration instructions on ARM

On Tue, Feb 10, 2009 at 18:45, Benjamin Schwartz wrote: > > Dear Python developers, > > Introduction: > I am writing from the perspective of Sugar Labs [1], which produces Sugar, > a > free software project written almost entirely in Python. Sugar is designed > to run on small, resource-constrain

Re: [Python-Dev] Tracker archeology

2009/2/11 Daniel (ajax) Diniz > Hi, > > Here's a status report about the digging. Thanks Benjamin, Antoine, > Martin, Raymond, Guilherme, Georg, Brett, Mark and everyone else for > helping :) > > Good: > Many requested assignments: >Thanks everyone that asked for bugs. If anyone else wants

Re: [Python-Dev] Tracker archeology

On Thu, Feb 12, 2009 at 05:08, Daniel (ajax) Diniz wrote: > Brett Cannon wrote: > > One thing to keep an eye on for old issues, Daniel, is the Stage > > field. Setting that is nice for Bug Days as people can see what > > issues still need a test written or could use a revi

Re: [Python-Dev] 3.0.1 and 2.6.2

On Thu, Feb 12, 2009 at 10:40, Barry Warsaw wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Feb 12, 2009, at 1:29 PM, Jesse Noller wrote: > > On Thu, Feb 12, 2009 at 1:20 PM, Antoine Pitrou >> wrote: >> >>> Jesse Noller gmail.com> writes: >>> I'm afraid I've gone bran

Re: [Python-Dev] Tracker archeology

On Thu, Feb 12, 2009 at 16:22, Stephen J. Turnbull wrote: > Brett Cannon writes: > > > Sounds like a "*verify issue* stage is needed. Although I guess I kind > of > > assumed as part of the triage issue verification would happen as well, > but > > that

Re: [Python-Dev] Tracker archeology

On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz wrote: > Stephen J. Turnbull wrote: > > Reproduction really is the same thing as providing a test. > > That was where I got confused: many issues are easy to reproduce > ('test'), but need some thinking to get automated tests right. > > urllib al

Re: [Python-Dev] Wow!

Is there a Python connection I'm missing? On Fri, Feb 13, 2009 at 13:12, Raymond Hettinger wrote: > > http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story > ___ > Python-Dev mailing list > Python-Dev@python.org > h

Re: [Python-Dev] The fate of 3.0.*

On Fri, Feb 13, 2009 at 18:35, Benjamin Peterson wrote: > Are we going to keep developing the 3.0 maintenance branch in > expectation of releasing 3.0.2 sometime or will we just focus our > efforts on 3.1? > I almost said "of course we are", but then I realized that 3.1 is going to be very simila

Re: [Python-Dev] The fate of 3.0.*

Don't rely on me getting importlib bootstrapped in by 3.1. It would be great if I pull it off, but I am afraid that is being optimistic. The library itself should definitely be done, though. On Feb 13, 2009 7:56 PM, "Antoine Pitrou" wrote: Benjamin Peterson python.org> writes: > > Are we going

Re: [Python-Dev] clarifying PEP 302 loader responsibilities upon failure

On Mon, Feb 9, 2009 at 14:02, Guido van Rossum wrote: > On Mon, Feb 9, 2009 at 1:56 PM, wrote: > > Guido and I were discussing what a loader should be responsible for when > > load_module is called and an exception is raised in relation to > sys.modules > > as PEP 302 says nothing about the top

Re: [Python-Dev] Closing outdated Mac issues

On Sun, Feb 15, 2009 at 12:13, Daniel (ajax) Diniz wrote: > Hi, > > In the discussion of a feature request for MacPython[1], the OP (hhas) > said: > >As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated >from the standard library and there are no longer any plans to su

Re: [Python-Dev] Tracker cleanup report

On Mon, Feb 16, 2009 at 12:37, Paul Moore wrote: > 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,

[Python-Dev] Anyone want to lead the sprints at PyCon this year?

Or am I doing it again as usual because I was stupid enough to ask this question? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/

Re: [Python-Dev] Tracker cleanup roadmap

On Tue, Feb 17, 2009 at 00:15, "Martin v. Löwis" wrote: > > Let's improve the tracker UI to better fit our needs. Then, classify > > them bugs and separate garbage from real development. Lastly, bug > > reporters should get a better UI. That's it, any help is welcome. > > The plan sounds great.

Re: [Python-Dev] Python 2.6.2 and 3.0.2

On Tue, Feb 17, 2009 at 12:18, Barry Warsaw wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thinking again about 3.0.2. > > If we'd like to do bug fix releases before Pycon, I suggest Monday March > 9th for code freeze and tagging. That would mean a Tuesday March 10th > release. > >

Re: [Python-Dev] IO implementation: in C and Python?

On Thu, Feb 19, 2009 at 19:41, Benjamin Peterson wrote: > As we prepare to merge the io-c branch, the question has come up [1] > about the original Python implementation. Should it just be deleted in > favor C version? The wish to maintain the two implementations together > has been raised on the

Re: [Python-Dev] IO implementation: in C and Python?

On Thu, Feb 19, 2009 at 21:35, Steven D'Aprano wrote: > Guido van Rossum wrote: > >> On Thu, Feb 19, 2009 at 8:38 PM, Brett Cannon wrote: >> >>> On Thu, Feb 19, 2009 at 19:41, Benjamin Peterson >>> wrote: >>> >>>> As we prepare to

[Python-Dev] Choosing a best practice solution for Python/extension modules

With io getting rewritten as an extension module, I think it's time to try to come up with a good best practice scenario for how to be able to control when a module uses a pure Python implementation and when it uses extension module optimizations. This is really only important for testing as if th

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach < dan...@stutzbachenterprises.com> wrote: > On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon wrote: > >> Now, from what I can tell, Antoine is suggesting having _pyio and a _io >> and then io is simply: >> >>

Re: [Python-Dev] Choosing a best practice solution for Python/extensionmodules

On Fri, Feb 20, 2009 at 12:33, Raymond Hettinger wrote: > [Brett] > >> With io getting rewritten as an extension module, I think it's time to try >> to come up with a good best practice scenario for how to be able to control >> when a module uses a pure Python implementation and when it uses ext

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

On Fri, Feb 20, 2009 at 12:37, Brett Cannon wrote: > > > On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach < > dan...@stutzbachenterprises.com> wrote: > >> On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon wrote: >> >>> Now, from what I can tell, Antoine is

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

On Fri, Feb 20, 2009 at 12:53, Aahz wrote: > On Fri, Feb 20, 2009, Brett Cannon wrote: > > On Fri, Feb 20, 2009 at 12:37, Brett Cannon wrote: > >> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach < > >> dan...@stutzbachenterprises.com> wrote: > >>>

Re: [Python-Dev] IO implementation: in C and Python?

On Fri, Feb 20, 2009 at 13:15, Greg Ewing wrote: > Steven D'Aprano wrote: > > Currently, if I want to verify that (say) cFoo and Foo do the same thing, >> or compare their speed, it's easy because I can import the modules >> separately. >> > > Also, won't foo.py be wasting time in most cases by >

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone wrote: > On Fri, 20 Feb 2009 13:45:26 -0800, Brett Cannon wrote: > >> On Fri, Feb 20, 2009 at 12:53, Aahz wrote: >> >> On Fri, Feb 20, 2009, Brett Cannon wrote: >>> > On Fri, Feb 20, 2009 at 12:37, Brett

<    10   11   12   13   14   15   16   17   18   19   >