Re: [Python-Dev] Stable ABI

[Ronald Oussoren]

> On 4 Jun 2018, at 08:35, Ronald Oussoren  wrote:
> 
> 
> 
>> On 3 Jun 2018, at 17:04, Eric V. Smith > > wrote:
>> 
>> On 6/3/2018 10:55 AM, Christian Tismer wrote:
>>> On 03.06.18 13:18, Ronald Oussoren wrote:
 
 
> On 3 Jun 2018, at 12:03, Christian Tismer  > wrote:
>>> ...
> 
> I have written a script that scans all relevant header files
> and analyses all sections which are reachable in the limited API
> context.
> All macros that don't begin with an underscore which contain
> a "->tp_" string are the locations which will break.
> 
> I found exactly 7 locations where this is the case.
> 
> My PR will contain the 7 fixes plus the analysis script
> to go into tools. Preparind that in the evening.
 
 Having tests would still be nice to detect changes to the stable ABI when 
 they are made.
 
 Writing those tests is quite some work though, especially if those at 
 least smoke test the limited ABI by compiling snippets the use all symbols 
 that should be exposed by the limited ABI. Writing those tests should be 
 fairly simple for someone that knows how to write C extensions, but is 
 some work.
 
 Writing a tests that complain when the headers expose symbols that 
 shouldn’t be exposed is harder, due to the need to parse headers (either 
 by hacking something together using regular expressions, or by using tools 
 like gccxml or clang’s C API).
>>> What do you mean?
>>> My script does that with all "tp_*" type fields.
>>> What else would you want to check?
>> 
>> I think Ronald is saying we're trying to answer a few questions:
>> 
>> 1. Did we accidentally drop anything from the stable ABI?
>> 
>> 2. Did we add anything to the stable ABI that we didn't mean to?
>> 
>> 3. (and one of mine): Does the stable ABI already contain things that we 
>> don't expect it to?
> 
> That’s correct.  There have been instances of the second item over the year, 
> and not all of them have been caught before releases.  What doesn’t help for 
> all of these is that the stable ABI documentation says that every documented 
> symbol is part of the stable ABI unless there’s explicit documentation to the 
> contrary. This makes researching if functions are intended to be part of the 
> stable ABI harder.
> 
> And also:
> 
> 4. Does the stable ABI actually work?
> 
> Christian’s script finds cases where exposed names don’t actually work when 
> you try to use them.

To reply to myself, the gist below is a very crude version of what I was trying 
to suggest:

https://gist.github.com/ronaldoussoren/fe4f80351a7ee72c245025df7b2ef1ed#file-gistfile1-txt
 


The gist is far from usable, but shows some tests that check that symbols in 
the stable ABI can be used, and tests that everything exported in the stable 
ABI is actually tested. 

Again, the code in the gist is a crude hack and I have currently no plans to 
turn this into something that could be added to the testsuite.

Ronald___
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] Stable ABI

[Ronald Oussoren]

> On 3 Jun 2018, at 17:04, Eric V. Smith  wrote:
> 
> On 6/3/2018 10:55 AM, Christian Tismer wrote:
>> On 03.06.18 13:18, Ronald Oussoren wrote:
>>> 
>>> 
 On 3 Jun 2018, at 12:03, Christian Tismer  wrote:
>> ...
 
 I have written a script that scans all relevant header files
 and analyses all sections which are reachable in the limited API
 context.
 All macros that don't begin with an underscore which contain
 a "->tp_" string are the locations which will break.
 
 I found exactly 7 locations where this is the case.
 
 My PR will contain the 7 fixes plus the analysis script
 to go into tools. Preparind that in the evening.
>>> 
>>> Having tests would still be nice to detect changes to the stable ABI when 
>>> they are made.
>>> 
>>> Writing those tests is quite some work though, especially if those at least 
>>> smoke test the limited ABI by compiling snippets the use all symbols that 
>>> should be exposed by the limited ABI. Writing those tests should be fairly 
>>> simple for someone that knows how to write C extensions, but is some work.
>>> 
>>> Writing a tests that complain when the headers expose symbols that 
>>> shouldn’t be exposed is harder, due to the need to parse headers (either by 
>>> hacking something together using regular expressions, or by using tools 
>>> like gccxml or clang’s C API).
>> What do you mean?
>> My script does that with all "tp_*" type fields.
>> What else would you want to check?
> 
> I think Ronald is saying we're trying to answer a few questions:
> 
> 1. Did we accidentally drop anything from the stable ABI?
> 
> 2. Did we add anything to the stable ABI that we didn't mean to?
> 
> 3. (and one of mine): Does the stable ABI already contain things that we 
> don't expect it to?

That’s correct.  There have been instances of the second item over the year, 
and not all of them have been caught before releases.  What doesn’t help for 
all of these is that the stable ABI documentation says that every documented 
symbol is part of the stable ABI unless there’s explicit documentation to the 
contrary. This makes researching if functions are intended to be part of the 
stable ABI harder.

And also:

4. Does the stable ABI actually work?

Christian’s script finds cases where exposed names don’t actually work when you 
try to use them.

Ronald

___
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] Stable ABI

[Eric Snow]

I've pointed out in bpo-21142 the similar script I added last year to
track C globals:

  https://github.com/python/cpython/tree/master/Tools/c-globals

-eric

On Mon, Jun 4, 2018 at 1:17 AM, Ronald Oussoren  wrote:
>
>
> On 4 Jun 2018, at 08:35, Ronald Oussoren  wrote:
>
>
>
> On 3 Jun 2018, at 17:04, Eric V. Smith  wrote:
>
> On 6/3/2018 10:55 AM, Christian Tismer wrote:
>
> On 03.06.18 13:18, Ronald Oussoren wrote:
>
>
>
> On 3 Jun 2018, at 12:03, Christian Tismer  wrote:
>
> ...
>
>
> I have written a script that scans all relevant header files
> and analyses all sections which are reachable in the limited API
> context.
> All macros that don't begin with an underscore which contain
> a "->tp_" string are the locations which will break.
>
> I found exactly 7 locations where this is the case.
>
> My PR will contain the 7 fixes plus the analysis script
> to go into tools. Preparind that in the evening.
>
>
> Having tests would still be nice to detect changes to the stable ABI when
> they are made.
>
> Writing those tests is quite some work though, especially if those at least
> smoke test the limited ABI by compiling snippets the use all symbols that
> should be exposed by the limited ABI. Writing those tests should be fairly
> simple for someone that knows how to write C extensions, but is some work.
>
> Writing a tests that complain when the headers expose symbols that shouldn’t
> be exposed is harder, due to the need to parse headers (either by hacking
> something together using regular expressions, or by using tools like gccxml
> or clang’s C API).
>
> What do you mean?
> My script does that with all "tp_*" type fields.
> What else would you want to check?
>
>
> I think Ronald is saying we're trying to answer a few questions:
>
> 1. Did we accidentally drop anything from the stable ABI?
>
> 2. Did we add anything to the stable ABI that we didn't mean to?
>
> 3. (and one of mine): Does the stable ABI already contain things that we
> don't expect it to?
>
>
> That’s correct.  There have been instances of the second item over the year,
> and not all of them have been caught before releases.  What doesn’t help for
> all of these is that the stable ABI documentation says that every documented
> symbol is part of the stable ABI unless there’s explicit documentation to
> the contrary. This makes researching if functions are intended to be part of
> the stable ABI harder.
>
> And also:
>
> 4. Does the stable ABI actually work?
>
> Christian’s script finds cases where exposed names don’t actually work when
> you try to use them.
>
>
> To reply to myself, the gist below is a very crude version of what I was
> trying to suggest:
>
> https://gist.github.com/ronaldoussoren/fe4f80351a7ee72c245025df7b2ef1ed#file-gistfile1-txt
>
> The gist is far from usable, but shows some tests that check that symbols in
> the stable ABI can be used, and tests that everything exported in the stable
> ABI is actually tested.
>
> Again, the code in the gist is a crude hack and I have currently no plans to
> turn this into something that could be added to the testsuite.
>
> Ronald
>
> ___
> 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/ericsnowcurrently%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] Microsoft to acquire GitHub for $7.5 billion

[Victor Stinner]

Hi,

It's now official: Microsoft is acquiring GitHub.

https://blog.github.com/2018-06-04-github-microsoft/
https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

I copy the news here since Python rely more and more on GitHub.

At this point, I have no opinion about the event :-) I just guess that
it should make GitHub more sustainable since Microsoft is a big
company with money and interest in GitHub. I'm also confident that
nothing will change soon. IMHO there is no need to worry about
anything.

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/archive%40mail-archive.com

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

[Antoine Pitrou]

On Mon, 4 Jun 2018 17:03:27 +0200
Victor Stinner  wrote:
> 
> At this point, I have no opinion about the event :-) I just guess that
> it should make GitHub more sustainable since Microsoft is a big
> company with money and interest in GitHub. I'm also confident that
> nothing will change soon. IMHO there is no need to worry about
> anything.

It does spell uncertainty on the long term.  While there is no need to
worry for now, I think it gives a different colour to the debate about
moving issues to Github.

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] Microsoft to acquire GitHub for $7.5 billion

[Guido van Rossum]

On Mon, Jun 4, 2018 at 8:40 AM, Antoine Pitrou  wrote:

>
> On Mon, 4 Jun 2018 17:03:27 +0200
> Victor Stinner  wrote:
> >
> > At this point, I have no opinion about the event :-) I just guess that
> > it should make GitHub more sustainable since Microsoft is a big
> > company with money and interest in GitHub. I'm also confident that
> > nothing will change soon. IMHO there is no need to worry about
> > anything.
>
> It does spell uncertainty on the long term.  While there is no need to
> worry for now, I think it gives a different colour to the debate about
> moving issues to Github.
>

I don't see how this *increases* the uncertainty. Surely if GitHub had
remained independent there would have been be similar concerns about how it
would make enough money to stay in business.

-- 
--Guido van Rossum (python.org/~guido)
___
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] Why not using "except: (...) raise" to cleanup on error?

[Victor Stinner]

Hi,

I just read a recent bugfix in asyncio:

https://github.com/python/cpython/commit/9602643120a509858d0bee4215d7f150e6125468

+ try:
+ await waiter
+ except Exception:
+ transport.close()
+ raise

Why only catching "except Exception:"? Why not also catching
KeyboardInterrupt or MemoryError? Is it a special rule for asyncio, or
a general policy in Python stdlib?

For me, it's fine to catch any exception using "except:" if the block
contains "raise", typical pattern to cleanup a resource in case of
error. Otherwise, there is a risk of leaking open file or not flushing
data on disk, for example.

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/archive%40mail-archive.com

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

[Victor Stinner]

2018-05-30 11:33 GMT+02:00 Victor Stinner :
> I fixed a few tests which failed randomly. There are still a few, but
> the most annoying have been fixed.

Quick update a few days later.

For an unknown reason,
test_multiprocessing_forkserver.TestIgnoreEINTR.test_ignore() started
to fail very frequently but only on Travis CI. I have no explanation
why only Travis CI. I failed to reproduce the issue on a Ubuntu Trusty
container or in a Ubuntu Trusty VM. After hours of debug, I found the
bug and wrote a fix. But the fix didn't work in all cases. A second
fix and now it seems like the issue is gone!

https://bugs.python.org/issue33532 if you are curious about the
strange multiprocessing send() which must block but it doesn't :-)

Except Windows 7 which has issues with test_asyncio and
multiprocessing tests because this buildbot is slow, it seems like
most CIs are now stable.

Known issues:

* PPC64 Fedora 3.x, PPC64LE Fedora 3.x, s390x RHEL 3.x:
https://bugs.python.org/issue33630
* AIX: always red
* USBan: experimental buildbot
* Alpine: platform not supported yet (musl issues)

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/archive%40mail-archive.com

Re: [Python-Dev] Why not using "except: (...) raise" to cleanup on error?

[Guido van Rossum]

It is currently a general convention in asyncio to only catch Exception,
not BaseException. I consider this a flaw and we should fix it, but it's
unfortunately not so easy -- the tests will fail if you replace all
occurrences of Exception with BaseException, and it is not always clear
what's the right thing to do. E.g. catching KeyboardInterrupt may actually
make it harder to stop a runaway asyncio app.

We should move this discussion to the issue tracker.

On Mon, Jun 4, 2018 at 9:11 AM, Victor Stinner  wrote:

> Hi,
>
> I just read a recent bugfix in asyncio:
>
> https://github.com/python/cpython/commit/9602643120a509858d0bee4215d7f1
> 50e6125468
>
> + try:
> + await waiter
> + except Exception:
> + transport.close()
> + raise
>
> Why only catching "except Exception:"? Why not also catching
> KeyboardInterrupt or MemoryError? Is it a special rule for asyncio, or
> a general policy in Python stdlib?
>
> For me, it's fine to catch any exception using "except:" if the block
> contains "raise", typical pattern to cleanup a resource in case of
> error. Otherwise, there is a risk of leaking open file or not flushing
> data on disk, for example.
>
> 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/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] Why not using "except: (...) raise" to cleanup on error?

[Chris Angelico]

On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner  wrote:
> Hi,
>
> I just read a recent bugfix in asyncio:
>
> https://github.com/python/cpython/commit/9602643120a509858d0bee4215d7f150e6125468
>
> + try:
> + await waiter
> + except Exception:
> + transport.close()
> + raise
>
> Why only catching "except Exception:"? Why not also catching
> KeyboardInterrupt or MemoryError? Is it a special rule for asyncio, or
> a general policy in Python stdlib?
>
> For me, it's fine to catch any exception using "except:" if the block
> contains "raise", typical pattern to cleanup a resource in case of
> error. Otherwise, there is a risk of leaking open file or not flushing
> data on disk, for example.

Pardon the dumb question, but why is try/finally unsuitable?

ChrisA
___
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] Why not using "except: (...) raise" to cleanup on error?

[Yury Selivanov]

> It is currently a general convention in asyncio to only catch Exception, not 
> BaseException. I consider this a flaw and we should fix it, but it's 
> unfortunately not so easy -- the tests will fail if you replace all 
> occurrences of Exception with BaseException, and it is not always clear 
> what's the right thing to do. E.g. catching KeyboardInterrupt may actually 
> make it harder to stop a runaway asyncio app.

Yes.

Catching BaseExceptions or KeyboardInterrupts in start_tls() would be
pointless. Currently asyncio's internal state isn't properly hardened
to survive a BaseException in all other places it can occur.  Fixing
that is one of my goals for 3.8.

Yury
___
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] Why not using "except: (...) raise" to cleanup on error?

[Yury Selivanov]

On Mon, Jun 4, 2018 at 12:50 PM Chris Angelico  wrote:
>
> On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner  wrote:
[..]
> > For me, it's fine to catch any exception using "except:" if the block
> > contains "raise", typical pattern to cleanup a resource in case of
> > error. Otherwise, there is a risk of leaking open file or not flushing
> > data on disk, for example.
>
> Pardon the dumb question, but why is try/finally unsuitable?

Because try..finally isn't equivalent to try..except?  Perhaps you
should look at the actual code:
https://github.com/python/cpython/blob/b609e687a076d77bdd687f5e4def85e29a044bfc/Lib/asyncio/base_events.py#L1117-L1123

Yury
___
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] Why not using "except: (...) raise" to cleanup on error?

[Chris Angelico]

On Tue, Jun 5, 2018 at 2:57 AM, Yury Selivanov  wrote:
> On Mon, Jun 4, 2018 at 12:50 PM Chris Angelico  wrote:
>>
>> On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner  wrote:
> [..]
>> > For me, it's fine to catch any exception using "except:" if the block
>> > contains "raise", typical pattern to cleanup a resource in case of
>> > error. Otherwise, there is a risk of leaking open file or not flushing
>> > data on disk, for example.
>>
>> Pardon the dumb question, but why is try/finally unsuitable?
>
> Because try..finally isn't equivalent to try..except?  Perhaps you
> should look at the actual code:
> https://github.com/python/cpython/blob/b609e687a076d77bdd687f5e4def85e29a044bfc/Lib/asyncio/base_events.py#L1117-L1123

Oh. Duh. Yep, it was a dumb question. Sorry! The transport should ONLY
be closed on error.

ChrisA
___
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

[Antoine Pitrou]

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.


On Mon, 4 Jun 2018 09:06:28 -0700
Guido van Rossum  wrote:
> On Mon, Jun 4, 2018 at 8:40 AM, Antoine Pitrou  wrote:
> 
> >
> > On Mon, 4 Jun 2018 17:03:27 +0200
> > Victor Stinner  wrote:  
> > >
> > > At this point, I have no opinion about the event :-) I just guess that
> > > it should make GitHub more sustainable since Microsoft is a big
> > > company with money and interest in GitHub. I'm also confident that
> > > nothing will change soon. IMHO there is no need to worry about
> > > anything.  
> >
> > It does spell uncertainty on the long term.  While there is no need to
> > worry for now, I think it gives a different colour to the debate about
> > moving issues to Github.
> >  
> 
> I don't see how this *increases* the uncertainty. Surely if GitHub had
> remained independent there would have been be similar concerns about how it
> would make enough money to stay in business.
> 

___
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] Microsoft to acquire GitHub for $7.5 billion

[Antoine Pitrou]

Le 04/06/2018 à 19:49, Mariatta Wijaya a écrit :
> 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.

What would talking to a MS or GH representative achieve?  Of course they
won't tell you if their company intend to disturb the current service in
a few years.

1) being mere employees they are forbidden to make such statements that
could hurt the company's bottom line;

2) they probably don't know themselves, since representatives aren't the
ones making decisions, and there's no reason they would be notified
months or years in advance.

So, if you talk to a representative, you will obviously get some
reassuring PR speak (which might be sincere btw).

All we are left with is to speculate on where the company's interests
lie.  It's not unknown for products or services to endure stark changes
after their provider is being bought by another entity.  Microsoft
themselves did it (see Skype), and of course others did as well.

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] Microsoft to acquire GitHub for $7.5 billion

[Ethan Furman]

On 06/04/2018 10:49 AM, Mariatta Wijaya wrote:


I think we shouldn't be speculating or making guesses.


We should have contingency plans and be prepared.  More than one bought-out competitor has simply disappeared, or been 
hamstrung in its effectiveness.


--
~Ethan~

___
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

[Ben Finney]

Ethan Furman  writes:

> On 06/04/2018 10:49 AM, Mariatta Wijaya wrote:
>
> > I think we shouldn't be speculating or making guesses.
>
> We should have contingency plans and be prepared. More than one
> bought-out competitor has simply disappeared, or been hamstrung in its
> effectiveness.

Yes. So, because such contingency plans take quite some time to prepare,
now *is* the time to be talking about it.

-- 
 \  “There's a certain part of the contented majority who love |
  `\anybody who is worth a billion dollars.” —John Kenneth |
_o__)Galbraith, 1992-05-23 |
Ben Finney

___
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] Why not using "except: (...) raise" to cleanup on error?

[Victor Stinner]

2018-06-04 18:45 GMT+02:00 Guido van Rossum :
> It is currently a general convention in asyncio to only catch Exception, not
> BaseException. I consider this a flaw and we should fix it, but it's
> unfortunately not so easy -- the tests will fail if you replace all
> occurrences of Exception with BaseException, and it is not always clear
> what's the right thing to do. E.g. catching KeyboardInterrupt may actually
> make it harder to stop a runaway asyncio app.

I recall vaguely something about loop.run_until_complete() which
didn't behave "as expected" when interrupted by CTRL+c, like the
following call to loop.run_until_complete() didn't work as expected.
But this issue has been sorted out, no?

I mean that maybe asyncio uses "except Exception:" for "historical reasons"?

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/archive%40mail-archive.com

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

[Ivan Pozdeev via Python-Dev]

No, replying only to you wasn't intended.

https://docs.travis-ci.com/user/running-build-in-debug-mode/ is the 
official doc on how to debug a Travis CI build via ssh.



On 04.06.2018 22:31, Victor Stinner wrote:

FYI you only replied to me in private. Is it on purpose?

I'm interested if I can learn how to get a SSH access to Travis CI!

2018-06-04 21:05 GMT+02:00 Ivan Pozdeev :

On 04.06.2018 19:31, Victor Stinner wrote:

2018-05-30 11:33 GMT+02:00 Victor Stinner :

I fixed a few tests which failed randomly. There are still a few, but
the most annoying have been fixed.

Quick update a few days later.

For an unknown reason,
test_multiprocessing_forkserver.TestIgnoreEINTR.test_ignore() started
to fail very frequently but only on Travis CI. I have no explanation
why only Travis CI. I failed to reproduce the issue on a Ubuntu Trusty
container or in a Ubuntu Trusty VM. After hours of debug, I found the
bug and wrote a fix. But the fix didn't work in all cases. A second
fix and now it seems like the issue is gone!


FYI Travis claim they provide ssh access on request to debug particularly
pesky issues.
Last time I tried, got no response from them though.


https://bugs.python.org/issue33532 if you are curious about the
strange multiprocessing send() which must block but it doesn't :-)

Except Windows 7 which has issues with test_asyncio and
multiprocessing tests because this buildbot is slow, it seems like
most CIs are now stable.

Known issues:

* PPC64 Fedora 3.x, PPC64LE Fedora 3.x, s390x RHEL 3.x:
https://bugs.python.org/issue33630
* AIX: always red
* USBan: experimental buildbot
* Alpine: platform not supported yet (musl issues)

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/vano%40mail.mipt.ru


--
Regards,
Ivan



--
Regards,
Ivan

___
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] Why not using "except: (...) raise" to cleanup on error?

[Yury Selivanov]

On Mon, Jun 4, 2018 at 3:38 PM Victor Stinner  wrote:
>
> 2018-06-04 18:45 GMT+02:00 Guido van Rossum :
> > It is currently a general convention in asyncio to only catch Exception, not
> > BaseException. I consider this a flaw and we should fix it, but it's
> > unfortunately not so easy -- the tests will fail if you replace all
> > occurrences of Exception with BaseException, and it is not always clear
> > what's the right thing to do. E.g. catching KeyboardInterrupt may actually
> > make it harder to stop a runaway asyncio app.
>
> I recall vaguely something about loop.run_until_complete() which
> didn't behave "as expected" when interrupted by CTRL+c, like the
> following call to loop.run_until_complete() didn't work as expected.
> But this issue has been sorted out, no?

No, the issue is still there.  And it's not an easy fix.

Yury
___
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

[Matěj Cepl]

On 2018-06-04, 16:06 GMT, Guido van Rossum wrote:
> I don't see how this *increases* the uncertainty. Surely if 
> GitHub had remained independent there would have been be 
> similar concerns about how it would make enough money to stay 
> in business.

Beacuse Microsoft is known to keep a money loosing venture 
around forever?

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
To err is human, to purr feline.

___
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

[Ivan Pozdeev via Python-Dev]

On 04.06.2018 21:46, Ethan Furman wrote:

On 06/04/2018 10:49 AM, Mariatta Wijaya wrote:


I think we shouldn't be speculating or making guesses.


We should have contingency plans and be prepared.  More than one 
bought-out competitor has simply disappeared, or been hamstrung in its 
effectiveness.


Actually, since M$ has closely integrated Python into VS, I'm expecting 
Guido to receive an acquisition offer next!



--
~Ethan~

___
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/vano%40mail.mipt.ru


--
Regards,
Ivan

___
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] Why not using "except: (...) raise" to cleanup on error?

[Ivan Pozdeev via Python-Dev]

On 04.06.2018 20:11, Chris Angelico wrote:

On Tue, Jun 5, 2018 at 2:57 AM, Yury Selivanov  wrote:

On Mon, Jun 4, 2018 at 12:50 PM Chris Angelico  wrote:

On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner  wrote:

[..]

For me, it's fine to catch any exception using "except:" if the block
contains "raise", typical pattern to cleanup a resource in case of
error. Otherwise, there is a risk of leaking open file or not flushing
data on disk, for example.

Pardon the dumb question, but why is try/finally unsuitable?

Because try..finally isn't equivalent to try..except?  Perhaps you
should look at the actual code:
https://github.com/python/cpython/blob/b609e687a076d77bdd687f5e4def85e29a044bfc/Lib/asyncio/base_events.py#L1117-L1123

Oh. Duh. Yep, it was a dumb question. Sorry! The transport should ONLY
be closed on error.


I smell a big, big design violation here.
The whole point of Exception vs BaseException is that anything not 
Exception is "not an error", has a completely different effect on the 
program than an error, and thus is to be dealt with completely 
differently. For example, warnings do not disrupt the control flow, and 
GeneratorExit is normally handled by the `for` loop machinery.

That's the whole point why except: is strongly discouraged.

Be _very_ careful because when a system has matured, the risk of making 
bad to disastrous design decisions skyrockets (because "the big picture" 
grows ever larger, and it's ever more difficult to account for all of it).


The best solution I know of is an independent sanity-check against the 
project's core design principles: focus solely on them and say if the 
suggestion is in harmony with the existing big picture. This prevents 
the project from falling victim to 
https://en.wikipedia.org/wiki/Design_by_committee in the long run. This 
is easier to do for someone not intimately involved with the change and 
the affected area 'cuz they are less biased in favor of the change and 
less distracted by minute details.


Someone may take up this role to "provide a unified vision" (to reduce 
the load on a single http://meatballwiki.org/wiki/BenevolentDictator , 
different projects have tried delegates (this can run afoul of 
https://en.wikipedia.org/wiki/Conway%27s_law though) and a round-robin 
approach (Apache)).
The best way, however, would probably be for anyone dealing with a 
design change to remember to make this check.


This is even easier in Python, 'cuz the core values are officially 
formulated as Python Zen, and any module has one or two governing 
principles at its core, tops, that can be extracted by skimming through 
its docs.



ChrisA
___
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/vano%40mail.mipt.ru


--
Regards,
Ivan

___
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] Docstrings on builtins

[Chris Barker via Python-Dev]

Over on python-ideas, someone is/was proposing literals for timedeltas.

I don't expect that will come to anything, but it did make me take a look
at the docstring for datetime.timedelta. I use iPython's ? a lot for a
quick overview of how to use a class/function.

This is what I get:

In [8]: timedelta?
Init signature: timedelta(self, /, *args, **kwargs)
Docstring:  Difference between two datetime values.
File:   ~/miniconda2/envs/py3/lib/python3.6/datetime.py
Type:   type


That is, well, not so useful. I'd like to see at least the signature:

datetime.timedelta(days=0, seconds=0, microseconds=0, milliseconds=0,
minutes=0, hours=0, weeks=0

And ideally much of the text in the docs.

I've noticed similarly minimal docstrings on a number of builtin functions
and methods.

If I wanted to contribute a PR to enhance these docstrings, where would
they go?  I've seen mention of "argument clinic", but really don't know
quite what that is, or how it works, but it appears to be related.

Anyway -- more comprehensive docstrings on buildins could really help
Python's usability for command line usage.

Thanks,
-  Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Why not using "except: (...) raise" to cleanup on error?

[Ivan Pozdeev via Python-Dev]

On 04.06.2018 23:52, Ivan Pozdeev wrote:

On 04.06.2018 20:11, Chris Angelico wrote:
On Tue, Jun 5, 2018 at 2:57 AM, Yury Selivanov 
 wrote:
On Mon, Jun 4, 2018 at 12:50 PM Chris Angelico  
wrote:
On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner 
 wrote:

[..]

For me, it's fine to catch any exception using "except:" if the block
contains "raise", typical pattern to cleanup a resource in case of
error. Otherwise, there is a risk of leaking open file or not 
flushing

data on disk, for example.

Pardon the dumb question, but why is try/finally unsuitable?

Because try..finally isn't equivalent to try..except?  Perhaps you
should look at the actual code:
https://github.com/python/cpython/blob/b609e687a076d77bdd687f5e4def85e29a044bfc/Lib/asyncio/base_events.py#L1117-L1123 



In this particular code, it looks like just KeyboardInterrupt needs to 
be handled in addition to Exception -- and even that's not certain 'cuz 
KeyboardInterrupt is an abnormal termination and specifically designed 
to not be messed with by the code ("The exception inherits from 
|BaseException| 
 
so as to not be accidentally caught by code that catches |Exception| 
 
and thus prevent the interpreter from exiting."). It only makes sense to 
catch it in REPL interfaces where the user clearly wants to terminale 
the current command rather than the entire program.


If e.g. a warning is upgraded to exception, this means that some code is 
broken from user's POV, but not from Python team's POV, so we can't 
really be sure if we can handle this situation gracefully: our cleanup 
code can fail just as well!



Oh. Duh. Yep, it was a dumb question. Sorry! The transport should ONLY
be closed on error.


I smell a big, big design violation here.
The whole point of Exception vs BaseException is that anything not 
Exception is "not an error", has a completely different effect on the 
program than an error, and thus is to be dealt with completely 
differently. For example, warnings do not disrupt the control flow, 
and GeneratorExit is normally handled by the `for` loop machinery.

That's the whole point why except: is strongly discouraged.

Be _very_ careful because when a system has matured, the risk of 
making bad to disastrous design decisions skyrockets (because "the big 
picture" grows ever larger, and it's ever more difficult to account 
for all of it).


The best solution I know of is an independent sanity-check against the 
project's core design principles: focus solely on them and say if the 
suggestion is in harmony with the existing big picture. This prevents 
the project from falling victim to 
https://en.wikipedia.org/wiki/Design_by_committee in the long run. 
This is easier to do for someone not intimately involved with the 
change and the affected area 'cuz they are less biased in favor of the 
change and less distracted by minute details.


Someone may take up this role to "provide a unified vision" (to reduce 
the load on a single http://meatballwiki.org/wiki/BenevolentDictator , 
different projects have tried delegates (this can run afoul of 
https://en.wikipedia.org/wiki/Conway%27s_law though) and a round-robin 
approach (Apache)).
The best way, however, would probably be for anyone dealing with a 
design change to remember to make this check.


This is even easier in Python, 'cuz the core values are officially 
formulated as Python Zen, and any module has one or two governing 
principles at its core, tops, that can be extracted by skimming 
through its docs.



ChrisA
___
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/vano%40mail.mipt.ru




--
Regards,
Ivan

___
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] Why not using "except: (...) raise" to cleanup on error?

[Ivan Pozdeev via Python-Dev]

On 05.06.2018 0:54, Ivan Pozdeev wrote:

On 04.06.2018 23:52, Ivan Pozdeev wrote:

On 04.06.2018 20:11, Chris Angelico wrote:
On Tue, Jun 5, 2018 at 2:57 AM, Yury Selivanov 
 wrote:
On Mon, Jun 4, 2018 at 12:50 PM Chris Angelico  
wrote:
On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner 
 wrote:

[..]
For me, it's fine to catch any exception using "except:" if the 
block

contains "raise", typical pattern to cleanup a resource in case of
error. Otherwise, there is a risk of leaking open file or not 
flushing

data on disk, for example.

Pardon the dumb question, but why is try/finally unsuitable?

Because try..finally isn't equivalent to try..except? Perhaps you
should look at the actual code:
https://github.com/python/cpython/blob/b609e687a076d77bdd687f5e4def85e29a044bfc/Lib/asyncio/base_events.py#L1117-L1123 



In this particular code, it looks like just KeyboardInterrupt needs to 
be handled in addition to Exception -- and even that's not certain 
'cuz KeyboardInterrupt is an abnormal termination and specifically 
designed to not be messed with by the code ("The exception inherits 
from |BaseException| 
 
so as to not be accidentally caught by code that catches |Exception| 
 
and thus prevent the interpreter from exiting.").




It only makes sense to catch it in REPL interfaces where the user 
clearly wants to terminale the current command rather than the entire 
program.


Remembered `pip`, too -- there, it's justified by it working in 
transactions.


If e.g. a warning is upgraded to exception, this means that some code 
is broken from user's POV, but not from Python team's POV, so we can't 
really be sure if we can handle this situation gracefully: our cleanup 
code can fail just as well!



Oh. Duh. Yep, it was a dumb question. Sorry! The transport should ONLY
be closed on error.


I smell a big, big design violation here.
The whole point of Exception vs BaseException is that anything not 
Exception is "not an error", has a completely different effect on the 
program than an error, and thus is to be dealt with completely 
differently. For example, warnings do not disrupt the control flow, 
and GeneratorExit is normally handled by the `for` loop machinery.

That's the whole point why except: is strongly discouraged.

Be _very_ careful because when a system has matured, the risk of 
making bad to disastrous design decisions skyrockets (because "the 
big picture" grows ever larger, and it's ever more difficult to 
account for all of it).


The best solution I know of is an independent sanity-check against 
the project's core design principles: focus solely on them and say if 
the suggestion is in harmony with the existing big picture. This 
prevents the project from falling victim to 
https://en.wikipedia.org/wiki/Design_by_committee in the long run. 
This is easier to do for someone not intimately involved with the 
change and the affected area 'cuz they are less biased in favor of 
the change and less distracted by minute details.


Someone may take up this role to "provide a unified vision" (to 
reduce the load on a single 
http://meatballwiki.org/wiki/BenevolentDictator , different projects 
have tried delegates (this can run afoul of 
https://en.wikipedia.org/wiki/Conway%27s_law though) and a 
round-robin approach (Apache)).
The best way, however, would probably be for anyone dealing with a 
design change to remember to make this check.


This is even easier in Python, 'cuz the core values are officially 
formulated as Python Zen, and any module has one or two governing 
principles at its core, tops, that can be extracted by skimming 
through its docs.



ChrisA
___
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/vano%40mail.mipt.ru




--
Regards,
Ivan


--
Regards,
Ivan

___
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] Docstrings on builtins

[Victor Stinner]

Hi,

For Argument Clinic, have a look at
https://docs.python.org/dev/howto/clinic.html

You can also try to copy/paste code from other files using Argument
Clinic and then run "make clinic" to regenerate the generated files.

Victor

2018-06-04 23:45 GMT+02:00 Chris Barker via Python-Dev :
> Over on python-ideas, someone is/was proposing literals for timedeltas.
>
> I don't expect that will come to anything, but it did make me take a look at
> the docstring for datetime.timedelta. I use iPython's ? a lot for a quick
> overview of how to use a class/function.
>
> This is what I get:
>
> In [8]: timedelta?
> Init signature: timedelta(self, /, *args, **kwargs)
> Docstring:  Difference between two datetime values.
> File:   ~/miniconda2/envs/py3/lib/python3.6/datetime.py
> Type:   type
>
>
> That is, well, not so useful. I'd like to see at least the signature:
>
> datetime.timedelta(days=0, seconds=0, microseconds=0, milliseconds=0,
> minutes=0, hours=0, weeks=0
>
> And ideally much of the text in the docs.
>
> I've noticed similarly minimal docstrings on a number of builtin functions
> and methods.
>
> If I wanted to contribute a PR to enhance these docstrings, where would they
> go?  I've seen mention of "argument clinic", but really don't know quite
> what that is, or how it works, but it appears to be related.
>
> Anyway -- more comprehensive docstrings on buildins could really help
> Python's usability for command line usage.
>
> Thanks,
> -  Chris
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> 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/vstinner%40redhat.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] Docstrings on builtins

[Chris Barker via Python-Dev]

On Mon, Jun 4, 2018 at 3:27 PM, Victor Stinner  wrote:

> For Argument Clinic, have a look at
> https://docs.python.org/dev/howto/clinic.html


Thanks Victor -- scanning that page, it is indeed where I needed to look.

You can also try to copy/paste code from other files using Argument
> Clinic and then run "make clinic" to regenerate the generated files.
>

good idea.

Now to find some time to actually work on this...

-CHB




> Victor
>
> 2018-06-04 23:45 GMT+02:00 Chris Barker via Python-Dev <
> python-dev@python.org>:
> > Over on python-ideas, someone is/was proposing literals for timedeltas.
> >
> > I don't expect that will come to anything, but it did make me take a
> look at
> > the docstring for datetime.timedelta. I use iPython's ? a lot for a quick
> > overview of how to use a class/function.
> >
> > This is what I get:
> >
> > In [8]: timedelta?
> > Init signature: timedelta(self, /, *args, **kwargs)
> > Docstring:  Difference between two datetime values.
> > File:   ~/miniconda2/envs/py3/lib/python3.6/datetime.py
> > Type:   type
> >
> >
> > That is, well, not so useful. I'd like to see at least the signature:
> >
> > datetime.timedelta(days=0, seconds=0, microseconds=0, milliseconds=0,
> > minutes=0, hours=0, weeks=0
> >
> > And ideally much of the text in the docs.
> >
> > I've noticed similarly minimal docstrings on a number of builtin
> functions
> > and methods.
> >
> > If I wanted to contribute a PR to enhance these docstrings, where would
> they
> > go?  I've seen mention of "argument clinic", but really don't know quite
> > what that is, or how it works, but it appears to be related.
> >
> > Anyway -- more comprehensive docstrings on buildins could really help
> > Python's usability for command line usage.
> >
> > Thanks,
> > -  Chris
> >
> >
> >
> >
> > --
> >
> > Christopher Barker, Ph.D.
> > Oceanographer
> >
> > Emergency Response Division
> > NOAA/NOS/OR&R(206) 526-6959   voice
> > 7600 Sand Point Way NE   (206) 526-6329   fax
> > Seattle, WA  98115   (206) 526-6317   main reception
> >
> > chris.bar...@noaa.gov
> >
> > ___
> > 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/vstinner%40redhat.com
> >
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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

[Steven D'Aprano]

On Mon, Jun 04, 2018 at 07:25:49PM +0200, Matěj Cepl wrote:
> On 2018-06-04, 16:06 GMT, Guido van Rossum wrote:
> > I don't see how this *increases* the uncertainty. Surely if 
> > GitHub had remained independent there would have been be 
> > similar concerns about how it would make enough money to stay 
> > in business.
> 
> Beacuse Microsoft is known to keep a money loosing venture 
> around forever?

No, but Guido is right: neither is anyone else.

In that regard, Microsoft is probably *more* likely to keep pumping 
money into a failing business if it gives them a strategic advantage, 
compared to other investors with no long-term strategy other than "get 
aquired by Google/Microsoft/Oracle/Apple".

But on the other hand, Microsoft (or at least the bad old Microsoft of 
Bill Gates' days) has a long history of "Embrace, Extend, Extinguish" 
as policy:

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

(Not that Microsoft is the only big tech company that does/did this.)

Anyway, this is just all speculation at this point. In the short term, 
nothing changes, and it is too early to tell how it changes the long 
term.


-- 
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/archive%40mail-archive.com

Re: [Python-Dev] Docstrings on builtins

[Matthias Bussonnier]

This may even be a bug/feature of IPython,

I see that inspect.signature(timedelta) fails, so if  timedelta? says
Init signature: timedelta(self, /, *args, **kwargs)
Then this may be some IPython internal logic. The timedelta class seem to
use __new__ instead of __init__ (not sure why) and __new__ have a
meaningful signature,
So maybe we should fallback on that during signature inspection.

Feel free to open an issue on the IPython repo.

Btw IPython is uppercase I, and we don't want any troupe with the fruit
giant.
-- 
M

On Mon, 4 Jun 2018 at 16:30, Chris Barker via Python-Dev <
python-dev@python.org> wrote:

> On Mon, Jun 4, 2018 at 3:27 PM, Victor Stinner 
> wrote:
>
>> For Argument Clinic, have a look at
>> https://docs.python.org/dev/howto/clinic.html
>
>
> Thanks Victor -- scanning that page, it is indeed where I needed to look.
>
> You can also try to copy/paste code from other files using Argument
>> Clinic and then run "make clinic" to regenerate the generated files.
>>
>
> good idea.
>
> Now to find some time to actually work on this...
>
> -CHB
>
>
>
>
>> Victor
>>
>> 2018-06-04 23:45 GMT+02:00 Chris Barker via Python-Dev <
>> python-dev@python.org>:
>> > Over on python-ideas, someone is/was proposing literals for timedeltas.
>> >
>> > I don't expect that will come to anything, but it did make me take a
>> look at
>> > the docstring for datetime.timedelta. I use iPython's ? a lot for a
>> quick
>> > overview of how to use a class/function.
>> >
>> > This is what I get:
>> >
>> > In [8]: timedelta?
>> > Init signature: timedelta(self, /, *args, **kwargs)
>> > Docstring:  Difference between two datetime values.
>> > File:   ~/miniconda2/envs/py3/lib/python3.6/datetime.py
>> > Type:   type
>> >
>> >
>> > That is, well, not so useful. I'd like to see at least the signature:
>> >
>> > datetime.timedelta(days=0, seconds=0, microseconds=0, milliseconds=0,
>> > minutes=0, hours=0, weeks=0
>> >
>> > And ideally much of the text in the docs.
>> >
>> > I've noticed similarly minimal docstrings on a number of builtin
>> functions
>> > and methods.
>> >
>> > If I wanted to contribute a PR to enhance these docstrings, where would
>> they
>> > go?  I've seen mention of "argument clinic", but really don't know quite
>> > what that is, or how it works, but it appears to be related.
>> >
>> > Anyway -- more comprehensive docstrings on buildins could really help
>> > Python's usability for command line usage.
>> >
>> > Thanks,
>> > -  Chris
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Christopher Barker, Ph.D.
>> > Oceanographer
>> >
>> > Emergency Response Division
>> > NOAA/NOS/OR&R(206) 526-6959   voice
>> > 7600 Sand Point Way NE   (206) 526-6329   fax
>> > Seattle, WA  98115   (206) 526-6317   main reception
>> >
>> > chris.bar...@noaa.gov
>> >
>> > ___
>> > 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/vstinner%40redhat.com
>> >
>>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
> ___
> 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/bussonniermatthias%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] Docstrings on builtins

[Ivan Pozdeev via Python-Dev]

On 05.06.2018 3:09, Matthias Bussonnier wrote:

This may even be a bug/feature of IPython,

I see that inspect.signature(timedelta) fails, so if timedelta? says
Init signature: timedelta(self, /, *args, **kwargs)
Then this may be some IPython internal logic. The timedelta class seem 
to use __new__ instead of __init__ (not sure why)


Because it's an immutable type.


and __new__ have a meaningful signature,
So maybe we should fallback on that during signature inspection.

According to 
https://stackoverflow.com/questions/4374006/check-for-mutability-in-python ,

there are no reliable tests for mutability.


Feel free to open an issue on the IPython repo.

Btw IPython is uppercase I, and we don't want any troupe with the 
fruit giant.

--
M

On Mon, 4 Jun 2018 at 16:30, Chris Barker via Python-Dev 
mailto:python-dev@python.org>> wrote:


On Mon, Jun 4, 2018 at 3:27 PM, Victor Stinner
mailto:vstin...@redhat.com>> wrote:

For Argument Clinic, have a look at
https://docs.python.org/dev/howto/clinic.html


Thanks Victor -- scanning that page, it is indeed where I needed
to look.

You can also try to copy/paste code from other files using
Argument
Clinic and then run "make clinic" to regenerate the generated
files.


good idea.

Now to find some time to actually work on this...

-CHB


Victor

2018-06-04 23:45 GMT+02:00 Chris Barker via Python-Dev
mailto:python-dev@python.org>>:
> Over on python-ideas, someone is/was proposing literals for
timedeltas.
>
> I don't expect that will come to anything, but it did make
me take a look at
> the docstring for datetime.timedelta. I use iPython's ? a
lot for a quick
> overview of how to use a class/function.
>
> This is what I get:
>
> In [8]: timedelta?
> Init signature: timedelta(self, /, *args, **kwargs)
> Docstring:      Difference between two datetime values.
> File:  ~/miniconda2/envs/py3/lib/python3.6/datetime.py
> Type:           type
>
>
> That is, well, not so useful. I'd like to see at least the
signature:
>
> datetime.timedelta(days=0, seconds=0, microseconds=0,
milliseconds=0,
> minutes=0, hours=0, weeks=0
>
> And ideally much of the text in the docs.
>
> I've noticed similarly minimal docstrings on a number of
builtin functions
> and methods.
>
> If I wanted to contribute a PR to enhance these docstrings,
where would they
> go?  I've seen mention of "argument clinic", but really
don't know quite
> what that is, or how it works, but it appears to be related.
>
> Anyway -- more comprehensive docstrings on buildins could
really help
> Python's usability for command line usage.
>
> Thanks,
> -  Chris
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959  voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317  main reception
>
> chris.bar...@noaa.gov 
>
> ___
> 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/vstinner%40redhat.com
>




-- 


Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov 
___
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/bussonniermatthias%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/vano%40mail.mipt.ru


--
Regards,
Ivan

___
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] Docstrings on builtins

[Chris Barker - NOAA Federal via Python-Dev]

>
> This may even be a bug/feature of IPython,

Ahh, thanks! I’ll look into that.

-CHB
___
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] Docstrings on builtins

[Matthias Bussonnier]

On Mon, 4 Jun 2018 at 17:29, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> On 05.06.2018 3:09, Matthias Bussonnier wrote:
>
> This may even be a bug/feature of IPython,
>
> I see that inspect.signature(timedelta) fails, so if  timedelta? says
> Init signature: timedelta(self, /, *args, **kwargs)
> Then this may be some IPython internal logic. The timedelta class seem to
> use __new__ instead of __init__ (not sure why)
>
> Because it's an immutable type.
>
Ah, yes, thanks.


> and __new__ have a meaningful signature,
> So maybe we should fallback on that during signature inspection.
>
> According to
> https://stackoverflow.com/questions/4374006/check-for-mutability-in-python
> ,
> there are no reliable tests for mutability.
>
Sure, but we can test if the signature of __init__ is (self,/, *args,
**kwargs), and if it is,  it is useless we can attempt to get the signature
from __new__ and show that instead.  We do similar things for docstrings,
if __init__ have no docstring we look at the class level docstring.
-- 
M
___
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