Re: [Python-Dev] Lost sight

[Mariatta Wijaya]

Sorry to hear that. Please take care.

On Sat, Jan 19, 2019, 4:15 AM Serhiy Storchaka  I have virtually completely lost the sight of my right eye (and the loss
> is quickly progresses) and the sight of my left eye is weak. That is why
> my activity as a core developer was decreased significantly at recent
> time. My apologies to those who are waiting for my review. I will do it
> slowly.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] any way to subscribe to bugs and PRs on a particular topic?

[Mariatta Wijaya]

For GitHub PRs, you can add yourself to CODEOWNERS file, so you will be
automatically requested review if a PR contains changes to unittest.mock.
(and you'll receive review-request notification)
https://github.com/python/cpython/blob/master/.github/CODEOWNERS

When GitHub sends you review request notification email, it will cc
review_reques...@noreply.github.com, so you can create a filter based on
that.
ᐧ

On Tue, Dec 4, 2018 at 11:21 AM Chris Withers  wrote:

> Hello,
>
> I'd like to see if I can help with unittest.mock, but don't have a huge
> amount of bandwidth and can't even parse let alone process the whole
> firehose of bpo and GH PRs.
>
> Is there  any way I can get bugs.python.org and github PRs to only tell
> me about things, preferably by email, that affect or involve unittest.mock?
>
> cheers,
>
> Chris
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Get a running instance of the doc for a PR.

[Mariatta Wijaya]

I think the intent is just uploading the output HTML and static assets.

I agree having the temporary output of PR docs build is useful, but I don't
think a python.org domain is necessary. If it can be uploaded to any cloud
storage service then that's good enough, just provide the link in the
status check. The output can be cleared after it receive the PR closed
webhook.

On Sun, Nov 4, 2018, 7:43 AM Serhiy Storchaka  04.11.18 17:00, Julien Palard via Python-Dev пише:
> > Considering feedback from Ned, what about building this as an
> independent service? We don't really need to interface with python.org at
> all, we just need some hardware, a domain, some code to interface with
> github API and... to start it's probably enough? It would be a usefull POC.
>
> This will just move risks to this service.
>
> Ned mentioned potential abuse. We will host unchecked content. Malicious
> user can create a PR which replaces Python documentation with malicious
> content.
>
> The Doc/ directory includes Python scripts and Makefile which are used
> for building documentation. Malicious user can use this for executing
> arbitrary code on our server.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Get a running instance of the doc for a PR.

[Mariatta Wijaya]

This will make review turnout quicker, since I can potentially review and
view the output from anywhere (phone while on a beach) instead of waiting
until I'm back home, open a computer, and then verify the output myself.

On Sun, Nov 4, 2018, 7:56 AM Steven D'Aprano  On Sun, Nov 04, 2018 at 04:12:39PM +0100, Stephane Wirtel wrote:
>
> > My workflow is the following steps:
> >
> > git wpr XYZ
> > cd ../cpython-XYZ
> > ./configure --prefix=$PWD-build --with-pydebug --silent
> > make -j 4 -s
> > make PYTHON=../python -C Doc/ venv
> > make -C Doc/ check suspicious html serve
> >
> > and run the browser on http://localhost:8000/ and check the result.
> >
> >
> > 1. Because I am a dev I can do it easily
> > 2. If you are not a dev, you have to learn a new step (download sources,
> > compile sources, compile doc and check the result)
>
> If I am making doc patches, shouldn't I be doing that *before* I
> submit the PR? How else will I know that my changes haven't broken the
> docs?
>
> So surely I need to learn those steps regardless?
>
> (Not a rhetorical question.)
>
>
> > I think this feature would be really useful for the contributors, the
> > reviewers and you, the core-dev.
>
> Sure. But the usefulness has to be weighed against the extra complexity,
> the extra "one more thing that can break and needs to be maintained",
> and the risk of abuse.
>
> I have no opinion on whether the pluses outweigh the minuses.
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Stop automerging

[Mariatta Wijaya]

Thanks Zach for fixing it quickly.

Even if that bug has been fixed, per my instructions to python-committers,
core devs should still edit the PR title and PR description *before* adding
the '烙 automerge' label.

The YouTube video (link in python-committers  email) shows to edit those.

The PR title and body will be used as the squashed commit message.

And remember, you can still merge the PR manually. Just don't apply the  '烙
automerge' label.

On Wed, Sep 12, 2018, 2:09 AM Zachary Ware 
wrote:

> It is still up to the core dev to set the message properly, but the HTML
> comments are invisible on GitHub until you edit the message. That bug is
> now fixed, though; HTML comments are stripped from the message before
> creating the commit.
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] make patchcheck and git path

[Mariatta Wijaya]

I don't quite understand the problem you're facing with git and make
patchcheck?

Also, perhaps this is more for core-workflow instead of python-dev.

Mariatta

ᐧ

On Fri, Aug 24, 2018 at 3:20 AM Michael  wrote:

> I am trying to be a 'good scout' and run "make patchcheck" more
> regularly. However, I generally am not successful because I build and
> test in separate directories.
>
> There is access to git! just no ready reference in the build area.
>
> So, not calling it a bug - but if someone else also experiences this,
> and feels capable of makeing it more flexible - you will get thanks from
> me, in any case!
>
> Michael
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7 EOL date

[Mariatta Wijaya]

No more security fixes after Jan 1, 2020.
It is the end of Python 2.7.



On Thu, Aug 23, 2018, 12:47 PM Collin Anderson  wrote:

> Hi All,
>
> Sorry if this has been mentioned before, but I noticed the Python 2.7 EOL
> date was recently set to Jan 1st, 2020.
>
> My understanding was Python releases get 5 years of support from their
> initial release, and Python 2.7 was extended an additional 5 years.
>
> Python 2.7 was originally released on 2010-07-03, and with an original EOL
> of 2015-07-03. Extended 5 years, shouldn't the EOL be 2020-07-03?
>
> Also, this statement is a little unclear to me:
>
> > Specifically, 2.7 will receive bugfix support until January 1, 2020. All
> 2.7 development work will cease in 2020.
>
> This statement makes it sound like bugfixes end on Jan 1st, but seems to
> leave open the possibility that security fixes could continue through the
> year.
>
> Thanks!
> Collin
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Problem in importing python packages under python 3.6 environment

[Mariatta Wijaya]

Hi Poornima,

Your question is more appropriate for the python-list mailing list (
https://mail.python.org/mailman/listinfo/python-list) or python-tutors
mailing list (https://mail.python.org/mailman/listinfo/tutor).



On Thu, Aug 9, 2018, 8:30 AM Poornima .D.  wrote:

> Hi All,
>
>
> I have limited knowledge on python development.  I am trying to write a
> test application which needs to import from many packages across
> mutliple directories.
>
>
> I tried using an environment variable and appending to sys.path variable
> so that import Class methods works.
>
>
> I am trying to replace the above logic by below syntax.
>
>
> from directory.fileName import ClassName
>
>
> But this syntax does not work.  Please let me know any solution for this
> issue.
>
>
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Refactor __get_builtin_constructor on hasklib.py

[Mariatta Wijaya]

2.7 is for bug fixes only. Unless there is a bug to be fixed, I would leave
the code as is.

Mariatta


On Tue, Aug 7, 2018 at 8:14 AM 蔡銘峯  wrote:

> Hello everybody,
> I am Park Tsai. I want to refactor __get_builtin_constructor on hasklib.py
> of python 2.7 (
> https://github.com/python/cpython/blob/2.7/Lib/hashlib.py#L72).
> This is the first time that I try to refactor code of CPython on GitHub,
> so I am very excited.
>
> This is __get_builtin_constructor code on hasklib.py ,as follows.
>
> def __get_builtin_constructor(name):
> try:
> if name in ('SHA1', 'sha1'):
> import _sha
> return _sha.new
> elif name in ('MD5', 'md5'):
> import _md5
> return _md5.new
> elif name in ('SHA256', 'sha256', 'SHA224', 'sha224'):
> import _sha256
> bs = name[3:]
> if bs == '256':
> return _sha256.sha256
> elif bs == '224':
> return _sha256.sha224
> elif name in ('SHA512', 'sha512', 'SHA384', 'sha384'):
> import _sha512
> bs = name[3:]
> if bs == '512':
> return _sha512.sha512
> elif bs == '384':
> return _sha512.sha384
> except ImportError:
> pass  # no extension module, this hash is unsupported.
>
> raise ValueError('unsupported hash type ' + name)
>
>
> When I read this code, it looks messy, so I want to refactor it and make
> it become more clearly .
>
> Then, it will be like this
>
> def get_builtin_constructor(name):
> try:
> if name[:3] in ('SHA','sha'):
>if(name[3:]=='1'):
>import _sha
>return _sha.new
>
>elif (name[3:] == '224'):
>import _sha256
>return _sha256.sha224
>
>elif (name[3:] == '256'):
>import _sha256
>return _sha256.sha256
>
>elif (name[3:] == '384'):
>import _sha512
>return _sha512.sha384
>
>elif (name[3:] == '512'):
>import _sha512
>return _sha512.sha512
> elif name in ('MD5', 'md5'):
> import _md5
> return _md5.new
>
> except ImportError:
> pass # no extension module, this hash is unsupported.
>
> raise ValueError('unsupported hash type ' + name)
>
> I will be grateful for any help you can provide. I really appreciate any
> feedback you can offer!
>
> Best regards,
> Park Tsai !!
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 b

[Mariatta Wijaya]

Backing up GitHub data has been brought up since the time we migrated to
GitHub, and being tracked here: https://github.com/pytho
n/core-workflow/issues/20

TL;DR We'll be using GitHub's new Migrations API
 to download archived
GitHub data of CPython. Ernest is helping us get set up with daily backups
of CPython repo to be stored within The PSF's infrastructure.

Mariatta

On Thu, Jun 7, 2018 at 11:24 AM, Chris Angelico  wrote:

> On Fri, Jun 8, 2018 at 3:33 AM, Chris Barker - NOAA Federal via
> Python-Dev  wrote:
> > Any service could change or fail. Period.
> >
> > So we shouldn’t want valuable information about Python development
> > only in gitHub.
> >
> > I don’t know how hard it is to backup / mirror an entire repo — but it
> > sure seems like a good idea.
>
> There are two separate concerns here:
>
> 1) How do we get a full copy of all of CPython and its change history?
>
> 2) How do we get all the non-code content - issues, pull requests,
> comments?
>
> The first one is trivially easy. *Everyone* who has a clone of the
> repository [1] has a full copy of the code and all history, updated
> every time 'git pull' is run.
>
> The second one depends on GitHub's exporting facilities; but it also
> depends on a definition of what's important. Maybe the PSF doesn't
> care if people's comments at the bottoms of commits are lost (not to
> be confused with commit messages themselves, which are part of the
> repo proper), so it wouldn't matter if they're lost. Or maybe it's
> important to have the contents of such commits, but it's okay to
> credit them to an email address rather than linking to an actual
> username. Or whatever. Unlike with the code/history repo, an imperfect
> export is still of partial value.
>
> ChrisA
>
> [1] Barring shallow clones, but most people don't do those
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>

ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression

[Mariatta Wijaya]

Are there APIs we can use to check the status of builbots?
Maybe we can have the our bots check for the buildbot status in backport
PRs.

On Wed, May 30, 2018, 2:33 AM Victor Stinner  wrote:

>
> Buildbots only send email notifications to buildbot-sta...@python.org
> when the state changes from success (green) to failure (red). It's
> much simpler for me to spot a regression when most buildbots are
> green.
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression

[Mariatta Wijaya]

Activating Travis CI GitHub app is being tracked in
https://github.com/python/core-workflow/issues/255

Let's not press the button until after the 3.7 release.


On Wed, Jun 6, 2018, 3:57 PM INADA Naoki  wrote:

> ​
> ​2018年6月7日(木) 2:44 Brett Cannon :
>
>>
>> On Wed, 6 Jun 2018 at 09:27 INADA Naoki  wrote:
>>
>>>  First I was also
 confused between travis-ci.com and travis-ci.org ... The documentation
 shows an example with .com, but Python organization uses .org.

 Victor

>>>
>>> .org is legacy.
>>>
>>> Open source projects can migrate to new .com.
>>>
>>
>> ... eventually: "existing user accounts and repositories will be migrated
>> over time." I have not seen any announcements or anything regarding how
>> when or how to migrate ourselves.
>>
>> -Brett
>>
>
> Before waiting notice from Travis-CI, we need to activate the repository
> on new site.
>
>
> https://docs.travis-ci.com/user/open-source-on-travis-ci-com/#Existing-Open-Source-Repositories-on-travis-ci.org
> > However, open source repositories will be migrated to travis-ci.com 
> > gradually,
> beginning at the end of Q2 2018. You will receive an email when the
> migration for a repository is complete. This is an opt-in process: to have
> a repository migrated over, it must first be activated on travis-ci.com.
>
> Could someone who is
> ​python org admin
> owner try activa
> ​​
> ting from here?
> https://travis-ci.com/profile/python
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 billion

[Mariatta Wijaya]

I think we shouldn't be speculating or making guesses.
If people are concerned with how Microsoft will manage GitHub, please talk
to Microsoft or GitHub representative, and not gossip in python-dev.

If there is actual news or announcement of how GitHub will change, and how
it will affect our workflow, we'll discuss in core-workflow.


Mariatta

On Mon, Jun 4, 2018 at 10:02 AM, Antoine Pitrou  wrote:

>
> That's true, but Microsoft has a lot of stakes in the ecosystem.
> For example, since it has its own CI service that it tries to promote
> (VSTS), is it in Microsoft's best interest to polish and improve
> integrations with other CI services?
>
> Regards
>
> Antoine
>
ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Mariatta Wijaya]

Can any of these said linters analyze only the diff in the PR, instead of
the entire CPython codebase?

Mariatta Wijaya

ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Mariatta Wijaya]

>
> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow


It's been great! Thanks!


> Said PEP may also need to mention the possibility of exporting
> > the history of GitHub issues, in case CPython ever migrates away from
> > GitHub; I remember that concern being raised when the original
> > migration was discussed.
> There are tools for it (e.g., I wrote
> https://github.com/mcepl/github-issues-export to move issues to
> Bugzilla, yes I am weird) and it is not that difficult to write
> something just to get data from GitHub’s all embracing arms. Of
> course, I am not sure how it would work on really large number
> of bugs, and it would be necessary to do some postprocessing
> (changing issue numbers etc.).


It's really more complicated than just copying over text from the bpo to
GitHub. Can we preserve the history and the existing discussions?
What about existing patches currently attached to issues? Can the issue
number be preserved?
Everywhere in our commit message we reference bpo-. What will happen to
those?
We'll need to come up with new workflow. How do we want to triage the
issues? And what does it mean to current bug tracker triage permission?

The recent
> improvements to @miss-islington (kudos to Mariatta!) allowing her to
> auto-backport PRs and commit them is a big time saver.


Thanks! I can't take all credit. The bots are easy to build and maintain
mainly because of Brett Cannon's gidgethub [1] library. Thanks Brett!
Also... is this a good time to advertise my PyCon tutorial [2] about
building GitHub bots?

 I still miss my “commit when CI completes” button, but oh well.


It is in my todo list, to at least notify when all CI completed so we can
go back and merge it.
I'll have time to think about this after PyCon US.

if there is a particular sticking point to please bring it up


This has been brought up several times in different mailing lists: Please
clean up the commit message before merging.

1. Ensure bpo-N is included.
If the bpo-N is not included, the commit doesn't get linked to the
issue in the b.p.o.

2. Ensure that the GitHub PR number is replaced, from (#12345) to (GH-12345)
In the b.p.o,  (#12345) links to bugs.python.org/issue12345 instead of
linking to GitHub PR number 12345.

3. Don't reference bpo-N as #N in the commit message.
tl;dr it breaks the bots. See [3] and [4]

One improvement I've been thinking about is related to the way we add news
entry using "blurb add" on the command line.
I wish there's a web UI for doing it. A place where I can type in the news
entry, give it the GitHub PR number, the bpo number, and with a button
click the News.d file magically created and added to the PR. Any thoughts
about this?


Mariatta Wijaya

[1] https://gidgethub.readthedocs.io/en/stable/
[2] https://us.pycon.org/2018/schedule/presentation/41/
[3] https://github.com/python/bedevere/issues/95#issuecomment-366570410
[4] https://github.com/python/bedevere/issues/97



ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

No problem :) It's been deployed.

Mariatta Wijaya

On Fri, Jan 26, 2018 at 9:48 AM, Eric V. Smith <e...@trueblade.com> wrote:
>
>
> It works for me: I think this is very helpful. Thanks for coding it up so
> quickly!
>
> Eric
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

>
> I believe https://github.com/python/bedevere/pull/82 will add a comment,
> which will get emailed to everyone nosy on the PR.

Yes, and I've just updated my PR description:

If a PR was merged and the commit message was not changed from # to
GH-, bedevere-bot will leave a comment to remind the core dev to update
it next time.
For example:
```
@Mariatta: Please replace # with GH- in the commit message next time.
Thanks!
```

Does that work for everyone?

Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

I think we're starting to deviate from the original topic here which is:
please replace # with GH- when you click Squash & Merge button.

The idea of the mergebot (by issuing a command) was brought up for a
different purpose: to automate the merging of a PR after all CI passes
(which can take time) and an approval by a core dev.
I still like that idea, if we can figure out a way to supply a commit
message we really want, before the bot merges the PR. It might be a
separate discussion for core-workflow or python-committers?

In my mind, even if we have such mergebot implemented, core devs can still
merge using the UI if they want to.
(Remember to replace the # with GH-)


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

>
> Why not just auto merge if the PR is approved, CI is all green, and no
> additional commits have been pushed?


My problem has been that I almost always still need to rewrite the commit
message.
Especially when someone wrote "fix a typo" or "fix several typos".

If it automatically merges, then there's no opportunity to adjust the
commit message.
So I suggest the option to provide the proper commit message to the
mergebot.
If not provided, I guess we'll use the GitHub PR title and description.

Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

>
> That would be best solution (I think it would solve
> https://github.com/python/miss-islington/issues/16 too) but it's more
> complicated than the extension idea :) I have some time work on it if
> you'd like to implement the mergebot idea.


+1 for the mergebot! :)

New bot or miss-islington's new job?

Still +1 either way, as long as other core devs are fine with it too :)


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

>
> Of course, we would still need to convince people to install it :)


Right, that's the challenge :)
I personally use Chrome (!) and I've been using your Chrome extension, so
thank you!
However, I don't feel comfortable making this available only for a specific
browser user, feels exclusionary to me.
Also, sometimes I merge from my phone where there's no chrome extension,
(maybe I really shouldn't be doing that?).

I think the solution should be something not webbrowser specific.

One idea is maybe have a bot to do the squash commit, for example by
commenting on GitHub:
@merge-bot merge  

So core devs can do the above instead of pressing the commit button. Any
thoughts on this?

In the meantime, committers, please try to remember and change the # into
GH- :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

It has to be manually edited right before you commit/merge on GitHub.
I don't think it can be automatically changed? Unless we have some kind of
post commit hook to amend the commit message.

I've been changing it to GH- , so does miss-islington when she backports.

If you see the mixed GH- and # in the backports PR, it's because
miss-islington converted the first one.

On Jan 25, 2018 4:21 AM, "Berker Peksağ"  wrote:

> On Thu, Jan 25, 2018 at 1:42 PM, INADA Naoki 
> wrote:
> > Hi.
> >
> > Devguide says:
> >
> > """
> > Replace the reference to GitHub pull request # with GH-. If
> > the title is too long, the pull request number can be added to the
> > message body.
> > """
> >
> > https://devguide.python.org/gitbootcamp/#accepting-and-
> merging-a-pull-request
> >
> > But there are more # than GH- in commit log.
> > https://github.com/python/cpython/commits/master
> >
> > Where should we go?
> > Encourage GH-? or abandon it and use default #?
>
> I'd personally drop both GH- and # markers. The number of the
> PR is already linked to the commit on GitHub:
> https://www.dropbox.com/s/zzm9f56485pbl1v/Screenshot%
> 20from%202018-01-25%2015%3A14%3A28.png?dl=0
>
> You can even see both styles in the same commit (especially in backport
> PRs)
>
>  bpo-42: Fix spam eggs (GH-2341) (#2211)
>
> --Berker
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] f-strings

[Mariatta Wijaya]

I agree it's useful info :)

I went ahead and made a PR [1].
In my PR, I simply linked to the Format Specification Mini Language[2] from
f-strings documentation[3].

Not sure about updating PEP 498 at this point..

[1] https://github.com/python/cpython/pull/4888

[2] https://docs.python.org/3.6/library/string.html#format-s
pecification-mini-language

[3]  https://docs.python.org/3/reference/lexical_analysis.html#f-strings
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] f-strings

[Mariatta Wijaya]

That's covered under "format specifiers" I think.
The PEP mentions this:
https://www.python.org/dev/peps/pep-0498/#format-specifiers

That specific example is not mentioned in the docs, but there other
examples of using format specifiers with f-strings.
https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals


On Dec 15, 2017 7:39 AM, "Wagner Herculano" <waghercul...@hotmail.com>
wrote:

> Good evening,
> I'm Wagner Herculano from Brazil.
> I was trying to do a table exercise with number 5 and tried formatting
> spaces and did not find it in PEP 498 documentation.
> Finally I found a way, if possible, include this example in the
> documentation please.
>
> Below is my script with the desired formatting about table of 5.
>
> *n = 5*
>
>
>
>
>
>
>
>
>
>
>
>
>
> *for i in range(1,11): print(f'{n} x {i:>2} = {n*i:>2}') Result5
> x  1 =  5 5 x  2 = 10 5 x  3 = 15 5 x  4 = 20 5 x  5 = 25 5 x  6 = 30 5 x
> 7 = 35 5 x  8 = 40 5 x  9 = 45 5 x 10 = 50*
> *---*
> *Sorry my English, I needed to use Google Translate*
>
> Best Regards,
> Wagner Herculano
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mariatta.
> wijaya%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "CPython loves your Pull Requests" talk by Stéphane Wirtel

[Mariatta Wijaya]

I saw the talk in person :) Congrats Stéphane!

You can get the reviews from a specific PR using the API:
https://developer.github.com/v3/pulls/reviews/#list-reviews-on-a-pull-request

For example, for reviews made to CPython PR number 1:

https://api.github.com/repos/python/cpython/pulls/1/reviews

* Time to merge a PR: 3 days in average, good!


Regarding the average time to merge PR, I'm interested to know the average
time to merge for PRs not made by Python Core Devs.


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs: ``.. code:: python`` or ``::`` (syntaxhighlighting)

[Mariatta Wijaya]

If we were to add Pygments support, it is to be done in pythondotorg
project.

I recalled the decision was to get PEPs rendered using Sphinx and host it
at Read The Docs, so we don't have to worry about updating pythondotorg.

Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

[Mariatta Wijaya]

-1 from me too.

Mariatta Wijaya

On Tue, Nov 28, 2017 at 12:38 PM, Barry Warsaw <ba...@python.org> wrote:

> On Nov 28, 2017, at 15:31, Raymond Hettinger <raymond.hettin...@gmail.com>
> wrote:
>
> > Put me down for a strong -1.   The proposal would occasionally save a
> few keystokes but comes at the expense of giving Python a more Perlish look
> and a more arcane feel.
>
> I am also -1.
>
> > One of the things I like about Python is that I can walk non-programmers
> through the code and explain what it does.  The examples in PEP 505 look
> like a step in the wrong direction.  They don't "look like Python" and make
> me feel like I have to decrypt the code to figure-out what it does.
>
> I had occasional to speak with someone very involved in Rust development.
> They have a process roughly similar to our PEPs.  One of the things he told
> me, which I found very interesting and have been mulling over for PEPs is,
> they require a section in their specification discussion how any new
> feature will be taught, both to new Rust programmers and experienced ones.
> I love the emphasis on teachability.  Sometimes I really miss that when
> considering some of the PEPs and the features they introduce (look how hard
> it is to teach asynchronous programming).
>
> Cheers,
> -Barry
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Migrate python-dev to Mailman 3?

[Mariatta Wijaya]

Starting with core-mentorship and then core-workflow sounds good.

Let me first find out what it's going to take to do the migration. (I
actually have no idea!)
I've sent an email to postmaster and asked for more details :)

Hope it's not too complicated...

Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Migrate python-dev to Mailman 3?

[Mariatta Wijaya]

Anything I can do to help make the migration to MM3 + HyperKitty happen? :)

Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Migrate python-dev to Mailman 3?

[Mariatta Wijaya]

> Except of Antoine Pitrou, does everybody else like the new UI? :-)

I love the new UI. +1000 for migrating.



Mariatta Wijaya

On Mon, Oct 30, 2017 at 8:57 AM, Stefan Krah <ste...@bytereef.org> wrote:

> On Mon, Oct 30, 2017 at 07:46:42AM -0700, Guido van Rossum wrote:
> > I love MM3 and hyperkitty. But I rarely peruse the archives -- I only go
> to
> > pipermail to get a link to a specific message from the past so I can copy
> > it into a current message. IIUC that functionality is actually better in
> > hyperkitty because when a pipermail archive is rebuilt the message
> numbers
> > come out differently.
>
> Yes, I use the archives differently.  When I'm temporarily unsubscribed
> due to overload I scan the archives for interesting topics and indeed
> sometimes read whole threads.
>
> I think Pipermail is great for that. Quiet design, nice font, good contrast
> for speed reading.
>
>
>
> Stefan Krah
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 561: Distributing and Packaging Type Information

[Mariatta Wijaya]

Ok I created an issue https://github.com/python/peps/issues/440, maybe
someone can work on updating the wordings in PEP 1 and PEP 12.
Thanks :)

Mariatta Wijaya

On Thu, Oct 26, 2017 at 5:03 PM, Guido van Rossum <gvanros...@gmail.com>
wrote:

> I think python-ideas does count here. Many PEPs evolve mostly there.
>
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 561: Distributing and Packaging Type Information

[Mariatta Wijaya]

>
> Not sure if postings to python-ideas count,


PEP 1 says:

Post-History is used to record the dates of when new versions of the PEP
are posted to python-list and/or python-dev.

So, no ?

Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pygments in PEPs?

[Mariatta Wijaya]

>
> For some unknown value of "soon". :-(


Well as soon as these tasks are done:

https://github.com/python/peps/projects/1


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cherry picker bot deployed in CPython repo

[Mariatta Wijaya]

Update:

Older merged PRs not yet backported?
==

A core developer can re-apply the `needs backport ..` label to trigger the
backport. Meaning, remove the existing label, then add it back. If there
was no label and now you want it to be backported, adding the label will
also trigger the backport.

Don't want PR to be backported by a bot?


Close the backport PR made by Miss Islington and make your own backport PR.


Thanks!



Mariatta Wijaya

On Tue, Sep 5, 2017 at 6:10 PM, Mariatta Wijaya <mariatta.wij...@gmail.com>
wrote:

> Hi,
>
> The cherry picker bot has just been deployed to CPython repo, codenamed
> miss-islington.
>
> miss-islington made the very first backport PR for CPython and became a
> first time GitHub contributor: https://github.com/python/cpython/pull/3369
>
>
> GitHub repo: https://github.com/python/miss-islington
>
> What is this?
> ==
>
> As part of our workflow, quite often changes made on the master branch
> need to be backported to the earlier versions. (for example: from master to
> 3.6 and 2.7)
>
> Previously the backport has to be done manually by either a core developer
> or the original PR author.
>
> With the bot, the backport PR is created automatically after the PR has
> been merged. A core developer will need to review the backport PR.
>
> The issue was tracked in https://github.com/python/core-workflow/issues/8
>
> How it works
> ==
>
> 1. If a PR needs to be backported to one of the maintenance branches, a
> core developer should apply the "needs backport to X.Y" label. Do this
> **before** you merge the PR.
>
> 2. Merge the PR
>
> 3. miss-islington will leave a comment on the PR, saying it is working on
> backporting the PR.
>
> 4. If there's no merge conflict, the PR should be created momentarily.
>
> 5. Review the backport PR created by miss-islington and merge it when
> you're ready.
>
> Merge Conflicts / Problems?
> ==
>
> In case of merge conflicts, or if a backport PR was not created within 2
> minutes, it likely failed and you should do the backport manually.
>
> Manual backport can be done using cherry_picker: https://pypi.
> org/project/cherry-picker/
>
> Older merged PRs not yet backported?
> ==
>
> At the moment, those need to be backported manually.
>
> Don't want PR to be backported by a bot?
> 
>
> My recommendation is to apply the "needs backport to X.Y" **after** the PR
> has been merged. The label is still useful to remind ourselves that this PR
> still needs backporting.
>
> Who is Miss Islington?
> =
>
> I found out from Wikipedia that Miss Islington is the name of the witch in
> Monty Python and The Holy Grail.
>
> miss-islington has not signed the CLA!
> =
>
> A core dev can ignore the warning and merge the PR anyway.
>
> Thanks!
>
>
> Mariatta Wijaya
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Cherry picker bot deployed in CPython repo

[Mariatta Wijaya]

Hi,

The cherry picker bot has just been deployed to CPython repo, codenamed
miss-islington.

miss-islington made the very first backport PR for CPython and became a
first time GitHub contributor: https://github.com/python/cpython/pull/3369

GitHub repo: https://github.com/python/miss-islington

What is this?
==

As part of our workflow, quite often changes made on the master branch need
to be backported to the earlier versions. (for example: from master to 3.6
and 2.7)

Previously the backport has to be done manually by either a core developer
or the original PR author.

With the bot, the backport PR is created automatically after the PR has
been merged. A core developer will need to review the backport PR.

The issue was tracked in https://github.com/python/core-workflow/issues/8

How it works
==

1. If a PR needs to be backported to one of the maintenance branches, a
core developer should apply the "needs backport to X.Y" label. Do this
**before** you merge the PR.

2. Merge the PR

3. miss-islington will leave a comment on the PR, saying it is working on
backporting the PR.

4. If there's no merge conflict, the PR should be created momentarily.

5. Review the backport PR created by miss-islington and merge it when
you're ready.

Merge Conflicts / Problems?
==

In case of merge conflicts, or if a backport PR was not created within 2
minutes, it likely failed and you should do the backport manually.

Manual backport can be done using cherry_picker:
https://pypi.org/project/cherry-picker/

Older merged PRs not yet backported?
==

At the moment, those need to be backported manually.

Don't want PR to be backported by a bot?


My recommendation is to apply the "needs backport to X.Y" **after** the PR
has been merged. The label is still useful to remind ourselves that this PR
still needs backporting.

Who is Miss Islington?
=

I found out from Wikipedia that Miss Islington is the name of the witch in
Monty Python and The Holy Grail.

miss-islington has not signed the CLA!
=

A core dev can ignore the warning and merge the PR anyway.

Thanks!


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] HTTPS on bugs.python.org

[Mariatta Wijaya]

I also would like the links from bug tracker emails be in https instead of
http.



On Sep 1, 2017 6:31 AM, "Antoine Pitrou"  wrote:

> On Fri, 1 Sep 2017 22:15:29 +0900
> INADA Naoki  wrote:
> > FYI, there is issue report for it.
> > http://psf.upfronthosting.co.za/roundup/meta/issue463
> > INADA Naoki  
>
> That issue is about making the tracker HTTPS-only, but fixing
> internal links to point to the HTTPS site would already go a long way,
> even without switching off HTTP access.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Git and Mercurial Security Update

[Mariatta Wijaya]

Thanks for the info Cheryl.

For those on Mac OS, you can update your local git using homebrew as
follows:

If you have installed git on MacOS using homebrew before:
$ brew upgrade git


If you did not install git using Homebrew, (for example if you've been
using the built-in git)
$ brew install git

`git --version` tells you what version you have. It should be 2.14.1 now.

On Windows, perhaps see
https://confluence.atlassian.com/bitbucketserver/installing-and-upgrading-git-776640906.html#InstallingandupgradingGit-InstallorupgradeGitonWindows




Mariatta Wijaya

On Sun, Aug 13, 2017 at 7:05 PM, rym...@gmail.com <rym...@gmail.com> wrote:

> Interesting, but does this really concern Python? I mean, it's hosted on
> GitHub and doesn't seem to recommend use of ssh URLs anyway...
>
>
> --
> Ryan (ライアン)
> Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone 
> elsehttp://refi64.com
>
> On Aug 13, 2017 at 8:11 PM, > wrote:
>
> http://www.esecurityplanet.com/threats/git-svn-and-
> mercurial-open-source-version-control-systems-update-for-
> critical-security-vulnerability.html
> ___ Python-Dev mailing list
> Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> rymg19%40gmail.com
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appending a link back to bugs.python.org in GitHub PRs

[Mariatta Wijaya]

Thanks for working on this, Kushal and Brett.

Works great!

Mariatta Wijaya

On Fri, Jul 21, 2017 at 2:28 PM, Brett Cannon <br...@python.org> wrote:

> Thanks to Kushal Das we now have one of the most requested features since
> the transition: a link in PRs back to bugs.python.org (in a more
> discoverable way since we have had them since Bedevere launched :) . When a
> pull request comes in with an issue number in the title (or one gets
> added), a link to bugs.python.org will be appended to the PR's body (the
> message you fill out when creating a PR). There's no logic to remove the
> link if the issue number is removed from the title, changed, or for
> multiple issue numbers since basically those cases are all rare and it was
> easier to launch without that kind of support.
>
> P.S.: Berker Peksag is working on providing commit emails with diffs in
> them which is the other most requested feature since the transition.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate invalid ctypes call protection on Windows

[Mariatta Wijaya]

Thanks all.

Documentation has been updated in  https://bugs.python.org/issue30470


On May 23, 2017 9:13 PM, "Victor Stinner"  wrote:

Sure, make your change and then update libffi!

Victor

Le 23 mai 2017 18:19, "Steve Dower"  a écrit :

> On 23May2017 1212, Victor Stinner wrote:
>
>> 2017-05-22 13:17 GMT-05:00 Steve Dower :
>>
>>> Once the special protection is removed, most of these cases will become
>>> OSError due to the general protection against segmentation faults.
>>>
>>
>> It didn't know that ctypes on Windows had a special protection against
>> programming errors. I'm not aware of such protection Linux. If you
>> call a function with the wrong number of arguments, it's likely to
>> crash or return random data.
>>
>> I guess that the point is to help debugging. But since Python 3.6,
>> faulthandler now registers a Windows exception handler and so it able
>> to dump the Python traceback on any Windows exception:
>> https://docs.python.org/dev/library/faulthandler.html#faulthandler.enable
>>
>> So I think that it's now fine to remove the ctypes protection. Just
>> advice (remind? ;-)) users to enable faulthandler: python3 -X
>> faulthandler, or call faulthandler.enable(). (You might want to use a
>> log file for that on Windows, depends on the use case.)
>>
>
> faulthandler is already recommended in the docs, and the existing SEH
> protection for access violations will remain (since that is independent of
> libffi).
>
> I'll be honest, I have appreciated the functionality in the past, but it
> really isn't good practice and getting rid of it will be an overall
> benefit. Technically even the segfault protection isn't a great idea, since
> you really do end up in an unknown state with regards to memory page
> allocations, but it's better than crashing all the way out.
>
> Cheers,
> Steve
>

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
mariatta.wijaya%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate invalid ctypes call protection on Windows

[Mariatta Wijaya]

+1

My understanding is this is a documentation change, marking it as
deprecated in 3.6.2 and a Misc News entry.
No actual code change.
Correct?



Mariatta Wijaya

On Tue, May 23, 2017 at 8:28 AM, Antoine Pitrou <solip...@pitrou.net> wrote:

> On Mon, 22 May 2017 11:17:18 -0700
> Steve Dower <steve.do...@python.org> wrote:
> >
> > I'd like to propose a highly-accelerated deprecation period for this
> > specific feature, starting in CPython 3.6.2 and being "completed" in
> > 3.7.0, when we will hopefully move onto a newer libffi.
> >
> > In general, the "feature" is a misfeature anyway, since calling a native
> > function with incorrect arguments is unsupported and a very easy way to
> > cause information leakage or code execution vulnerabilities.
>
> Agreed.
>
> > Does anyone have any reasons to oppose this? It already has votes from
> > another Windows expert and the 3.6/3.7 Release Manager, but we wanted to
> > see if anyone has a concern we haven't thought of.
>
> +1 from me.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible bug in class-init, lookin for mentors

[Mariatta Wijaya]

Justus, welcome.

Consider joining the core-mentorship mailing list. If you have specific
questions on how to contribute or how to get started, we can help you
there. https://mail.python.org/mailman/listinfo/core-mentorship

Thanks, Erik. Yes, CPython has moved to GitHub https://github.com/python/
cpython but we will continue using bugs.python.org as the issue tracker.
We prefer that discussions happen on the issue tracker, and GitHub is for
code reviewing only.

The Dev Guide has been updated with our new GitHub workflow, specifically:
http://cpython-devguide.readthedocs.io/pullrequest.html
http://cpython-devguide.readthedocs.io/gitbootcamp.html

Thanks :)


Mariatta Wijaya

On Tue, May 2, 2017 at 9:01 AM, Erik Bray <erik.m.b...@gmail.com> wrote:

> On Fri, Apr 21, 2017 at 12:09 PM, Justus Schwabedal
> <jschwabe...@gmail.com> wrote:
> > Hi everyone,
> >
> > I possibly found a bug in class initialization and would like to fix it.
> > Because it's my first journey to core-dev, I would really appreciate the
> > help of a mentor that I may ask a few questions to get me up to speed.
> >
> > To my person, I have previously worked on larger projects in python, c,
> and
> > c++ if that information helps, and I'm really curious to learn more about
> > the interiors of the greatest interpreter known to wo-/men.
> >
> > Here comes the bug-producing example:
> >
> > `class Foo:
> > def __init__(self, bar=[]):
> > self.list = bar
> >
> > spam_1 = Foo()
> > spam_2 = Foo()
> >
> > spam_1.list.append(42)
> > print(spam_2.list)`
> >
> > At least I think it's a bug.  Maybe it's a feature..
>
> Sorry to resurrect an old-ish thread; I haven't looked at Python-dev
> in several weeks.  I just wanted to point out that while everyone on
> this thread pointed out how this isn't a bug (clear to anyone who's
> spent enough time with Python), we have here an experienced C/C++
> developer who is interested in helping out on Python core devel, and
> no one took him up on that offer.
>
> Jus, for what it's worth, there are a slew of *actual* Python bugs to
> be worked on--many languishing for years--due to lack of available
> developer time.  You can have a good look at the (daunting) list of
> bugs at the old bugs.python.org [1].  IIUC Python development is
> slowly moving over to GitHub, but the issue list hasn't migrated yet
> so that would still be the place to start.
>
> If you find a bug that looks worth your time to try to fix, you should
> probably follow up on the issue for that bug itself.  I can't make any
> promises anyone will have time for mentorship, but I'd be willing to
> point you in the right direction.  I'm not a core developer but I know
> Python internals reasonably well and might be able to help *depending*
> on the issue.
>
> Best,
> Erik
>
> [1] http://bugs.python.org/
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Please use #9999 when writing a new PEP

[Mariatta Wijaya]

Hi everyone,

>From now on, when proposing a new PEP, please use the number . This
allows Travis build to pass, while waiting for a PEP editor to assign you a
number.

This means, in the header of your draft PEP, instead of ``PEP: XXX``, you
should now use ``PEP: ``.
You should name the file ``pep-.rst``, instead of ``pep-.rst``.

Both PEP 1 and PEP 12 have been updated to address this.

Thanks :)


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Questions on the CPython Git master branch: how to exclude commits of 3.x branches?

[Mariatta Wijaya]

Can you try

git log master ^3.6

I think it will give what's on master and not in 3.6



On Mar 31, 2017 8:47 AM, "Victor Stinner"  wrote:

> Hi,
>
> The CPython repository was converted from Mercurial to Git. Before
> with Mercurial, we used extensively merges. For example, a bug was
> fixed in branche 3.5, merged into 3.6 and then merged into master.
> With the conversion to Git, some merges commit are removed, some
> others are kept.
>
> My question is how to list commits which are only part of the "master"
> branch, as "hg log default" in Mercurial. "git log origin/master"
> lists also commits coming from 3.x branches and their merges. The
> problem is that if you pick a commit from a different branch, you
> compile Python 3.x, instead of compiling Python for the master branch.
>
> Right now, my need is to find the first commit in the "master" branch
> after a specific date. For example, find the first commit after
> 2016-01-01 00:00.
>
> Naive solution:
> ---
> $ git log --since="2016-01-01 00:00" origin/master --reverse|head
> commit 75e3630c6071819d3674d956ea754ccb4fed5271
> Author: Benjamin Peterson 
> Date:   Fri Jan 1 10:23:45 2016 -0600
>
> 2016 will be another year of writing copyrighted code
> ---
>
> If you compile the revision 75e3630c6071819d3674d956ea754ccb4fed5271,
> you get Python 3.3:
> ---
> $ grep PY_M Include/patchlevel.h
> #define PY_MAJOR_VERSION3
> #define PY_MINOR_VERSION3
> #define PY_MICRO_VERSION6
> ---
>
> But if you exclude manually commits which are in branches 3.x, you get
> the commit 71db903563906cedfc098418659d1200043cd14c which gives a
> different Python version:
> ---
> $ grep PY_M Include/patchlevel.h
> #define PY_MAJOR_VERSION3
> #define PY_MINOR_VERSION6
> #define PY_MICRO_VERSION0
> ---
>
> In fact, I wrote a tool to manually exclude commits of branches 3.x:
>
> https://github.com/haypo/misc/blob/master/misc/find_git_
> revisions_by_date.py
>
> But it's super slow! Are there builtin options to only show Git
> commits which are in master branch but not in 3.x branches?
>
> Asked differently: how can I only see two commits on the following
> range? What are [options]?
>
> git rev-list 288cb25f1a208fe09b9e06ba479e11c1157da4b5..
> 71db903563906cedfc098418659d1200043cd14c
> [options]
>
> Commits after 2016-01-01:
> ---
> $ git checkout 71db903563906cedfc098418659d1200043cd14c
> $ git log --graph
> *   commit 71db903563906cedfc098418659d1200043cd14c
> |\  Merge: 288cb25 4c70293
> | | Author: Benjamin Peterson 
> | | Date:   Fri Jan 1 10:25:22 2016 -0600
> | |
> | | merge 3.5
> | |
> | *   commit 4c70293755ce8ea0adc5b224c714da2b7625d232
> | |\  Merge: 42bf8fc e8c2a95
> | | | Author: Benjamin Peterson 
> | | | Date:   Fri Jan 1 10:25:12 2016 -0600
> | | |
> | | | merge 3.4
> | | |
> | | *   commit e8c2a957c87980a1fd79c39597d40e5c5aeb7048
> | | |\  Merge: 52d6c2c 75e3630
> | | | | Author: Benjamin Peterson 
> | | | | Date:   Fri Jan 1 10:24:21 2016 -0600
> | | | |
> | | | | merge 3.3
> | | | |
> | | | * commit 75e3630c6071819d3674d956ea754ccb4fed5271
> | | | | Author: Benjamin Peterson 
> | | | | Date:   Fri Jan 1 10:23:45 2016 -0600
> | | | |
> | | | | 2016 will be another year of writing copyrighted code
> | | | |
> * | | |   commit 288cb25f1a208fe09b9e06ba479e11c1157da4b5
> |\ \ \ \  Merge: 58f8833 42bf8fc
> | |/ / /  Author: Serhiy Storchaka 
> | | | |   Date:   Wed Dec 30 21:41:53 2015 +0200
> | | | |
> | | | |   Issue #25961: Disallowed null characters in the type name.
> | | | |   Simplified testing for null characters in __name__ setter.
> | | | |
> ---
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Update to PEP 1 re: content type

[Mariatta Wijaya]

Hello,

PEP 1 states that plain/text is an acceptable value for a PEP's content
type, and it is the default value if no content type is specified.

May I propose adding something along the line of: "new PEPs should use
restructured Text format", and that reST format becomes the default.

Based on couple tickets in peps repo, it seems like the reST format is
preferred anyway, and there have been thoughts about converting text based
PEPs into reST format
https://github.com/python/peps/issues/4
https://github.com/python/peps/issues/2

I hope this is not too controversial.
Discussed this with Guido earlier. He is supportive, and asked me to send
email to python-dev :)

Thanks


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com