Re: [Python-Dev] configparser: should optionxform be idempotent?

On Fri, 8 Mar 2019 at 02:54, Inada Naoki wrote: > > Personally speaking, I think technical jargon is much easier than > normal English idioms or complex English syntax. > > I learned "idempotent" long ago while learning HTTP. On the other hand, > I don't know normal English idioms even 5-year chi

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, 7 Mar 2019 at 23:58, Greg Ewing wrote: > > Paul Moore wrote: > > There's a subtle difference in the mathematical > > and computing meanings [of idempotent] (around functions > > with side-effects, which aren't a thing in maths) > > Not really an issue here, since optionxform shouldn't be

Re: [Python-Dev] Using CLA assistant for Python contributions

On Fri, 8 Mar 2019 at 02:32, Mariatta wrote: > > Thought I'll be a little more clearer: you'll need to re-sign the CLA only > for your future contributions (aka when you make new pull request to Python). My preference would be to just re-sign the CLA *immediately*, and not wait for when I have a

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On Fri, Mar 8, 2019 at 12:41 AM Mariatta wrote: > I'd like to formally present to Python-dev PEP 581: Using GitHub Issues > for CPython > > Full text: https://www.python.org/dev/peps/pep-0581/ > > Thanks a lot for doing this! * The current bug tracker has low contributions and moving to a place

Re: [Python-Dev] configparser: should optionxform be idempotent?

> > > We could say something like: > > > >"The optionxform function transforms option names to a > >canonical form. If the name is already in canonical form, > >it should be returned unchanged." > > How about: > > "The optionxform function transforms option names to a > canonica

Re: [Python-Dev] Using CLA assistant for Python contributions

Thought I'll be a little more clearer: you'll need to re-sign the CLA only for your future contributions (aka when you make new pull request to Python). Your previous CLA record are still available for The PSF, we're just not going to export over data from existing CLA host to CLA assistant. ᐧ ᐧ _

Re: [Python-Dev] Using CLA assistant for Python contributions

> > I plan to > > switch us over to to CLA assistant in the coming week (before my OOOS of > > March 18) > OOOS? My Out Of Open Source aka I'm not doing any volunteer activities for 6 weeks (details: https://discuss.python.org/t/mariatta-will-be-ooos-out-of-open-source-starting-march-18-may-9th-2

Re: [Python-Dev] Using CLA assistant for Python contributions

On Thu, Mar 07, 2019 at 10:49:50AM -0800, Mariatta wrote: > Unless I hear strong opposition (with reasons) from Python Steering > Council, Python core developers, and active core contributors, I plan to > switch us over to to CLA assistant in the coming week (before my OOOS of > March 18) OOOS? O

[Python-Dev] PEP 12 updated with templates for header fields and sections

https://github.com/python/peps/blob/master/pep-0012.rst now has a complete list of header fields along with format clues for easier copy-and-paste use in creating a new PEP. There is also a section template with one-liner explanations for what each section is for so people don't accidentally leave

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

I'll start by saying I don't think a history lesson is important for this PEP. This is simply a matter of evaluating whether Roundup or GitHub issues is better for us and in the future. There's no real mistakes to watch out for or anything (and if there is it's that self-hosting has a cost ;) . On

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Fri, Mar 08, 2019 at 12:56:13PM +1300, Greg Ewing wrote: > In any case, the word is easy enough to avoid in this case. I don't think we should avoid using standard terminology even if we can. Knowledge of standard terminology is useful, and we don't generally make a practice of talking about

Re: [Python-Dev] configparser: should optionxform be idempotent?

Paul Moore wrote: There's a subtle difference in the mathematical and computing meanings [of idempotent] (around functions > with side-effects, which aren't a thing in maths) Not really an issue here, since optionxform shouldn't be having side effects if it's sane. In any case, the word is eas

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On Mar 7, 2019, at 14:36, Mariatta wrote: > I was not involved in core Python development back then, so if it is really > important and if people think such paragraph needs to be part of the PEP, > then perhaps someone else more knowledgeable will need to help with this. > > Personally, I don'

Re: [Python-Dev] configparser: should optionxform be idempotent?

Inada Naoki wrote: a) Document "optionxform must be idempotent". b) Ensure all APIs calls optionxform exactly once, and document >[that it must be idempotent in certain special situations]. I think the question that needs to be asked is whether optionxform is meant to be a canonicalisi

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

I've made the PR about "not closing all issues": https://github.com/python/peps/pull/917/files ᐧ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On Thu, Mar 7, 2019 at 2:12 PM Mariatta wrote: > > On Thu, Mar 7, 2019 at 12:35 PM Matthew Woodcraft > wrote: > >> >> One part of this PEP stands out to me: >> >> | We should not be moving all open issues to GitHub. Issues with little >> | or no activity should just be closed. Issues with no dec

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On Thu, Mar 7, 2019 at 2:02 PM Skip Montanaro wrote: > I think it would be worthwhile to mention a couple > reasons, when the decision was made to use Roundup, etc. Without it, a > casual reader might think the core devs made a horrible mistake way > back when, and are only now getting around to

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On Thu, Mar 7, 2019 at 12:36 PM Manuel Cerón wrote: > > After some frustration with bpo, I decided to file some issues into the > meta tracker, just to find out that the link [1] provided by the Python > Developer's Guide [2] is broken, giving a connection timeout. > > Sometime ago we've started

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On Thu, Mar 7, 2019 at 12:35 PM Matthew Woodcraft wrote: > > One part of this PEP stands out to me: > > | We should not be moving all open issues to GitHub. Issues with little > | or no activity should just be closed. Issues with no decision made for > | years should just be closed. > > I strongl

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

> I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for > CPython > > Full text: https://www.python.org/dev/peps/pep-0581/ Thanks for doing this. I think there is a pretty strong argument to be made that mature, widely adopted systems like GitHub (or GitLab or Bitbucket) sho

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On 07/03/2019 19.08, Mariatta wrote: I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for CPython Full text: https://www.python.org/dev/peps/pep-0581/ This is my first PEP, and in my opinion it is ready for wider discussion. One part of this PEP stands out to me: | We

Re: [Python-Dev] Loading modules from a folder

Cool, thanks! My apologies - i'll post the question there instead. On Thu, 7 Mar 2019 at 18:41 Brett Cannon wrote: > This mailing list is actually for the development *of* Python, not *with* > Python. You can try asking your question on Stack Overflow, python tutor, > or python-list. > > On Thu

[Python-Dev] PEP 581: Using GitHub Issues for CPython

I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for CPython Full text: https://www.python.org/dev/peps/pep-0581/ This is my first PEP, and in my opinion it is ready for wider discussion. I don't know if it is "ready for pronouncement" so I'm hoping to get more guidance abo

[Python-Dev] Using CLA assistant for Python contributions

I've posted in Discourse under core-workflow category , and this has been previously discussed on the core-workflow mailing list

Re: [Python-Dev] Loading modules from a folder

This mailing list is actually for the development *of* Python, not *with* Python. You can try asking your question on Stack Overflow, python tutor, or python-list. On Thu, Mar 7, 2019 at 9:28 AM Mani Sarkar wrote: > Hi, > > I have seen multiple ways to load modules from a folder. > > Say I have

[Python-Dev] Loading modules from a folder

Hi, I have seen multiple ways to load modules from a folder. Say I have a folder src which contains a number of folders each one of them is a module. What are the conventional ways to load modules from such a folder? I have used >From src.[module] import x But I don't want to use the src

Re: [Python-Dev] configparser: should optionxform be idempotent?

07.03.19 11:18, Inada Naoki пише: So what should we do about optionxform? a) Document "optionxform must be idempotent". b) Ensure all APIs calls optionxform exactly once, and document "When you get option name from section objects, it is already optionxform-ed. You can not reuse the

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, 7 Mar 2019 at 12:42, Steven D'Aprano wrote: > > I'm not keen on the term "idempotent" here - I wasn't at all clear > > what it was intended to convey. But from looking at the bug report, I > > see that it basically means "optionxform should be a function which, > > when applied more than

Re: [Python-Dev] Compact ordered set

ordered set 2 Hi, Raymond. Thank you for your detailed response and I'm sorry about the late reply. All of your points make sense to me. My implementation has not been battle-tested yet. As I wrote in a previous mail, there is only one benchmark in pyperformance was affected significantly. (M

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, Mar 07, 2019 at 09:56:49AM +, Paul Moore wrote: > On Thu, 7 Mar 2019 at 09:21, Inada Naoki wrote: > > The document of the optionxform shows example > > overrides it to identity function `lambda option: option`. > > https://docs.python.org/3/library/configparser.html#configparser.Config

Re: [Python-Dev] configparser: should optionxform be idempotent?

> > That argument could be used for any use of optionxform, though - > instead of using the default optionxform, use explicitly-lowercased > values everywhere instead. > It can't be usable if the config format case-insensitive. value = (cfg.get("section", "name") or cfg.get("section", "Name")

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, 7 Mar 2019 at 10:06, Inada Naoki wrote: > > On Thu, Mar 7, 2019 at 6:57 PM Paul Moore wrote: > > > > I'm not keen on the term "idempotent" here - I wasn't at all clear > > what it was intended to convey. But from looking at the bug report, I > > see that it basically means "optionxform sh

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, Mar 7, 2019 at 2:51 PM Inada Naoki wrote: > Hi, all. > > I came from https://bugs.python.org/issue35838 > Since there are no "expert" for configparser in > Expert Index, I ask here to make design decision. > There is lukasz.langa in the expert index for configparser at https://devguide.p

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, Mar 7, 2019 at 6:57 PM Paul Moore wrote: > > I'm not keen on the term "idempotent" here - I wasn't at all clear > what it was intended to convey. But from looking at the bug report, I > see that it basically means "optionxform should be a function which, > when applied more than one time t

Re: [Python-Dev] configparser: should optionxform be idempotent?

On Thu, 7 Mar 2019 at 09:21, Inada Naoki wrote: > The document of the optionxform shows example > overrides it to identity function `lambda option: option`. > https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform > > BPO-35838 is issue about optionxform can be c

[Python-Dev] configparser: should optionxform be idempotent?

Hi, all. I came from https://bugs.python.org/issue35838 Since there are no "expert" for configparser in Expert Index, I ask here to make design decision. The default behavior of CofigParser.optionxform is str.lowercase(). This is used to canonicalize option key names. The document of the option