Re: [Python-Dev] socketserver ForkingMixin waiting for child processes

[Ryan Smith-Roberts]

I agree that blocking shutdown by default isn't a good idea. A child will
eventually get indefinitely stuck on a nonresponsive connection and hang
the whole server. This behavior change is surprising and should be reverted
in master, and definitely not backported.

As for block-timeout or block-timeout-kill, waiting more than zero seconds
in server_close() should be optional, because you're right that the best
timeout is circumstantial. Since ThreadingMixIn also leaks threads,
server_close() could grow a timeout flag (following the socket module
timeout convention) and maybe a terminate boolean. ThreadingMixIn could
then also be fixed. I'm not sure how useful that is though, since I'd bet
almost all users of socketserver exit the process shortly after
server_close(). Plus it can't be backported to the feature-freeze branches.

It seems like this is getting complicated enough that putting the fix in
test_socketserver.py is probably best. Another solution is to add a secret
terminating-close flag to ForkingMixIn just for the tests. Is that good
practice in the stdlib?

On Fri, Aug 11, 2017 at 6:46 AM Victor Stinner 
wrote:

> Hi,
>
> I'm working on reducing the failure rate of Python CIs (Travis CI,
> AppVeyor, buildbots). For that, I'm trying to reduce test side effects
> using "environment altered" warnings. This week, I worked on
> support.reap_children() which detects leaked child processes (usually
> created with os.fork()).
>
> I found a bug in the socketserver module: it waits for child processes
> completion, but only in non-blocking mode. If a child process takes
> too long, the server will never reads its exit status and so the
> server leaks "zombie processes". Leaking processes can increase the
> memory usage, spawning new processes can fail, etc.
>
> => http://bugs.python.org/issue31151
>
> I changed the code to call waitpid() in blocking mode on each child
> process on server_close(), to ensure that all children completed when
> on server close:
>
>
> https://github.com/python/cpython/commit/aa8ec34ad52bb3b274ce91169e1bc4a598655049
>
> After pushing my change, I'm not sure anymore if it's a good idea.
> There is a risk that server_close() blocks if a child is stuck on a
> socket recv() or send() for some reasons.
>
> Should we relax the code by waiting a few seconds (problem: hardcoded
> timeouts are always a bad idea), or *terminate* processes (SIGKILL on
> UNIX) if they don't complete fast enough?
>
> I don't know which applications use socketserver. How I can test if it
> breaks code in the wild?
>
> At least, I didn't notice any regression on Python CIs.
>
> Well, maybe the change is ok for the master branch. But I would like
> your opinion because now I would like to backport the fix to 2.7 and
> 3.6 branches. It might break some applications.
>
> If we *cannot* backport such change to 2.7 and 3.6 because it changes
> the behaviour, I will fix the bug in test_socketserver.py instead.
>
> What do you think?
>
> 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/rmsr%40lab.net
>
___
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] Tunning binary insertion sort algorithm in Timsort.

[Ryan Smith-Roberts]

I suspect that you will find the Python community extremely conservative
about any changes to its sorting algorithm, given that it took thirteen
years and some really impressive automated verification software to find
this bug:

http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/

On Sun, Mar 8, 2015 at 5:17 PM, nha pham phq...@gmail.com wrote:

 We can optimize the TimSort algorithm by optimizing its binary insertion
 sort.



 The current version of binary insertion sort use this idea:

 Use binary search to find a final position in sorted list for a new
 element X. Then insert X to that location.



 I suggest another idea:

 Use binary search to find a final postion in sorted list for a new element
 X. Before insert X to that location, compare X with its next element.

 For the next element, we already know if it is lower or bigger than X, so
 we can reduce the search area to the left side or on the right side of X in
 the sorted list.



 I have applied my idea on java.util. ComparableTimSort.sort() and testing.
 The execute time is reduced by 2%-6% with array of random integer.



 Here is detail about algorithm and testing:
 https://github.com/nhapq/Optimize_binary_insertion_sort



 Sincerely.

 phqnha

 ___
 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/rmsr%40lab.net


___
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] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan Smith-Roberts]

I'm not an official cpython developer but ifdef __ANDROID__ is quite in
line with other per-platform support (__FreeBSD__, __linux__, etc), as well
as already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not
being defined when it should be?

On Thu, Feb 26, 2015 at 4:20 PM, Ryan Gonzalez rym...@gmail.com wrote:

 DOES NOBODY HAVE AN ANSWER TO THIS???

 I'm REALLY relying on someone who works on Python to answer this. PLEASE??

 On Wed, Feb 25, 2015 at 12:17 PM, Ryan Gonzalez rym...@gmail.com wrote:

 So...

 There was a recent discussion here on porting Python to Android. Well,
 for those of you who saw too many unread messages and marked the whole
 thread as read like I usually do, I helped Cyd figure out some patches that
 make it work. Cyd then opened Issue 23496
 http://bugs.python.org/issue23496. Now, I'm going to try to redo the
 patches against HEAD (or tip in Mercurial language).

 Which leads me to the question. See, of course, the patches should only
 be enabled if Python is being built targeting Android, but I'm not sure how
 that should be detected.

 I know that the Android target triple is arm-linux-androideabi. Should I
 test for the __ANDROID__ macro in the source file, or should I modify
 configure.ac to detect Android and define its own macro? Also, if a
 configure.ac edit is preferred, where should it be? It's slightly
 painful to scan through all 4000 lines of Python's configure script. ;)

 --
 Ryan
 If anybody ever asks me why I prefer C++ to C, my answer will be simple:
 It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
 nul-terminated.
 Personal reality distortion fields are immune to contradictory evidence.
 - srean
 Check out my website: http://kirbyfan64.github.io/




 --
 Ryan
 If anybody ever asks me why I prefer C++ to C, my answer will be simple:
 It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
 nul-terminated.
 Personal reality distortion fields are immune to contradictory evidence. -
 srean
 Check out my website: http://kirbyfan64.github.io/

 ___
 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/rmsr%40lab.net


___
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] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan Smith-Roberts]

On Thu, Feb 26, 2015 at 5:13 PM, Ryan Smith-Roberts r...@lab.net wrote:
 I'm not an official cpython developer but ifdef __ANDROID__ is quite in line
 with other per-platform support (__FreeBSD__, __linux__, etc), as well as
 already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not being
 defined when it should be?

Might as well spend the time to answer my own question:

Some Googling indicates that __ANDROID__ is baked into the NDK
toolchain, so it's definitely what one would use to wrap
Android-specific code.

__ANDROID__ shall always be defined by the toolchain, without a need
for special flags though, so please rely on that instead in your
code. - David Turner, Android NDK Lead, 2010.
___
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] Using argument clinic to replace timemodule.c:parse_time_t_args()

[Ryan Smith-Roberts]

The trick you're missing is that *any time* you have an optional argument
with a custom converter[1], PyArg_ParseTuple *only* calls the converter
function in the case that the user *actually supplies some value*. This is
a basic property of an optional argument. Another property is that the
c_default is evaluated *every time*, as it is set *before* the call to
PyArg_ParseTuple. Are these the best ways to do things? Maybe not, but it's
how they are.

Please do not use a custom converter for this case. It can't work. Please
do what I outlined earlier (untested, somewhat verbose code follows):

static int
parse_time_t_arg(PyObject *arg, time_t *when)
{
if (arg == NULL || arg == Py_None) {
*when = time(NULL);
return 1;
}
if (_PyTime_ObjectToTime_t(arg, when) == -1)
return 0;
return 1;
}

/*[clinic input]
time.gmtime
seconds: object = None
[clinic start generated code]*/
{
time_t when;

if (0 == parse_time_t_arg(seconds, when))
return NULL;
...


[1] If you set a default value, or put it in brackets as Serhiy later
recommends, it works the same.


On Sun, Jan 19, 2014 at 8:19 PM, Nikolaus Rath nikol...@rath.org wrote:

 Larry Hastings la...@hastings.org writes:
  On 01/18/2014 09:52 PM, Ryan Smith-Roberts wrote:
 
  I still advise you not to use this solution. time() is a system call
  on many operating systems, and so it can be a heavier operation than
  you'd think. Best to avoid it unless it's needed (on FreeBSD it
  seems to add about 15% overhead to localtime(), for instance).
 
 
  I agree.  Converting to Argument Clinic should not cause a performance
  regression.  Please don't add new calls to time() for the sake of
  making code more generic.
 
  A better choice would be to write a converter function in C, then use
  a custom converter that called it.  Nikolaus: Is that something you're
  comfortable doing?

 I think I'll need some help. I don't know how to handle the case where
 the user is not passing anything.

 Here's my attempt:

 ,
 | /* C Converter for argument clinic
 |If obj is NULL or Py_None, return current time. Otherwise,
 |convert Python object to time_t.
 | */
 | static int
 | PyObject_to_time_t(PyObject *obj, time_t *stamp)
 | {
 | if (obj == NULL || obj == Py_None) {
 | *stamp = time(NULL);
 | }
 | else {
 | if (_PyTime_ObjectToTime_t(obj, stamp) == -1)
 | return 0;
 | }
 | return 1;
 | }
 |
 | /*[python input]
 | class time_t_converter(CConverter):
 | type = 'time_t'
 | converter = 'PyObject_to_time_t'
 | default = None
 | [python start generated code]*/
 | /*[python end generated code:
 checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/
 |
 |
 | /*[clinic input]
 | time.gmtime
 |
 | seconds: time_t
 | /
 |
 | [clinic start generated code]*/
 `

 but this results in the following code:

 ,
 | static PyObject *
 | time_gmtime(PyModuleDef *module, PyObject *args)
 | {
 | PyObject *return_value = NULL;
 | time_t seconds;
 |
 | if (!PyArg_ParseTuple(args,
 | |O:gmtime,
 | PyObject_to_time_t, seconds))
 | goto exit;
 | return_value = time_gmtime_impl(module, seconds);
 |
 | exit:
 | return return_value;
 | }
 `

 This works if the user calls time.gmtime(None), but it fails for
 time.gmtime(). It seems that in that case my C converter function is
 never called.

 What's the trick that I'm missing?


 Thanks!
 -Nikolaus

 --
 Encrypted emails preferred.  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6
 02CF A9AD B7F8 AE4E 425C

  »Time flies like an arrow, fruit flies like a Banana.«
 ___
 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/rmsr%40lab.net

___
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] Using argument clinic to replace timemodule.c:parse_time_t_args()

[Ryan Smith-Roberts]

On Sun, Jan 19, 2014 at 2:38 AM, Larry Hastings la...@hastings.org wrote:

  According to the issue tracker,  rmsr has only ever filed one issue.
 I just fixed (and closed) it.


The two issues were custom converter with converter and default raises
exception and custom converter with py_default and c_default being
overridden by __init__.

As for the former, you said I hope you know what you're doing! which made
me step back and think more about the why. I realized two things:

The default-related class attributes might be an 'attractive nuisance', in
that setting them there technically saves repetition, but could easily
confuse a later reader who expects to find the defaults declared inline as
usual.

As well, it is unclear which of 'default', 'py_default', 'c_default' one
needs to set, or which has priority. Nikolaus went ahead and set all three,
thus my bug reports. After tinkering some more with the test file for the
first bug, I noticed that a class with 'default' and 'converter' generates
a default in the signature line but not at the C level.

I'm wondering now if class-level default support shouldn't just be removed,
as the aforementioned attractive nuisance.
___
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] Using argument clinic to replace timemodule.c:parse_time_t_args()

[Ryan Smith-Roberts]

Hi Nikolaus. I also started a conversion of timemodule, but dropped it when
I saw in the issue that you had taken over that conversion. I also tried to
turn parse_time_t_args into a converter. However, it won't work. The
problem is that parse_time_t_args must be called whether or not the user
supplies an argument to the function, but an Argument Clinic converter only
gets called if the user actually supplies something, and not on the default
value.

So, the best idea is to

* Remove the PyArgs_ParseTuple code from parse_time_t_args
* Declare seconds as a plain object in Argument Clinic
* Call the modified parse_time_t_args on seconds first thing in the _impl
functions


On Sat, Jan 18, 2014 at 4:56 PM, Nikolaus Rath nikol...@rath.org wrote:

 Hello,

 I'm trying to convert functions using parse_time_t_args() (from
 timemodule.c) for argument parsing to argument clinic.

 The function is defined as:

 ,
 | static int
 | parse_time_t_args(PyObject *args, char *format, time_t *pwhen)
 | {
 | PyObject *ot = NULL;
 | time_t whent;
 |
 | if (!PyArg_ParseTuple(args, format, ot))
 | return 0;
 | if (ot == NULL || ot == Py_None) {
 | whent = time(NULL);
 | }
 | else {
 | if (_PyTime_ObjectToTime_t(ot, whent) == -1)
 | return 0;
 | }
 | *pwhen = whent;
 | return 1;
 | }
 `

 and used like this:

 ,
 | static PyObject *
 | time_localtime(PyObject *self, PyObject *args)
 | {
 | time_t when;
 | struct tm buf;
 |
 | if (!parse_time_t_args(args, |O:localtime, when))
 | return NULL;
 | if (pylocaltime(when, buf) == -1)
 | return NULL;
 | return tmtotuple(buf);
 | }
 `

 In other words, if any Python object is passed to it, it calls
 _PyTime_ObjectToTime_t on it to convert it to time_t, and otherwise uses
 time(NULL) as the default value.

 May first attempt to implement something similar in argument clinic was:

 ,
 | /*[python input]
 | class time_t_converter(CConverter):
 | type = 'time_t'
 | converter = 'time_t_converter'
 | default = None
 | py_default = 'None'
 | c_default = 'time(NULL)'
 | converter = '_PyTime_ObjectToTime_t'
 | [python start generated code]*/
 |
 | /*[clinic input]
 | time.localtime
 |
 | seconds: time_t
 | /
 |
 | bla.
 | [clinic start generated code]*/
 `

 However, running clinic.py on this file gives:

 ,
 | $ Tools/clinic/clinic.py Modules/timemodule.c
 | Error in file Modules/timemodule.c on line 529:
 | Exception raised during parsing:
 | Traceback (most recent call last):
 |   File Tools/clinic/clinic.py, line 1445, in parse
 | parser.parse(block)
 |   File Tools/clinic/clinic.py, line 2738, in parse
 | self.state(None)
 |   File Tools/clinic/clinic.py, line 3468, in state_terminal
 | self.function.docstring = self.format_docstring()
 |   File Tools/clinic/clinic.py, line 3344, in format_docstring
 | s += .join(a)
 | TypeError: sequence item 2: expected str instance, NoneType found
 `

 What am I doing wrong?


 Best,
 Nikolaus

 --
 Encrypted emails preferred.
 PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

  »Time flies like an arrow, fruit flies like a Banana.«
 ___
 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/rmsr%40lab.net

___
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] Using argument clinic to replace timemodule.c:parse_time_t_args()

[Ryan Smith-Roberts]

Ah yes, my apologies, I was thrown off by the first converter declaration
in your class and didn't spot the second, so didn't realize what you were
up to.

I still advise you not to use this solution. time() is a system call on
many operating systems, and so it can be a heavier operation than you'd
think. Best to avoid it unless it's needed (on FreeBSD it seems to add
about 15% overhead to localtime(), for instance).

As for why you're getting that exception, it definitely looks like a bug in
Argument Clinic. I spotted another bug that would have bitten you while I
was looking for this one, so I've opened bugs on both issues, and put you
on the nosy list for them.


On Sat, Jan 18, 2014 at 7:42 PM, Nikolaus Rath nikol...@rath.org wrote:

 Hi Ryan,


 Ryan Smith-Roberts r...@lab.net writes:
  Hi Nikolaus. I also started a conversion of timemodule, but dropped it
 when
  I saw in the issue that you had taken over that conversion. I also tried
 to
  turn parse_time_t_args into a converter. However, it won't work. The
  problem is that parse_time_t_args must be called whether or not the user
  supplies an argument to the function, but an Argument Clinic converter
 only
  gets called if the user actually supplies something, and not on the
 default
  value.

 I don't quite follow. My approach was to drop parse_time_t_args()
 completely and use _PyTime_ObjectToTime_t() as the conversion function
 (which only needs to be called if the user supplied something).

 In other words, I would have expected

  ,
  | /*[python input]
  | class time_t_converter(CConverter):
  | type = 'time_t'
  | converter = 'time_t_converter'
  | default = None
  | py_default = 'None'
  | c_default = 'time(NULL)'
  | converter = '_PyTime_ObjectToTime_t'
  | [python start generated code]*/
  |
  | /*[clinic input]
  | time.localtime
  |
  | seconds: time_t
  | /
  |
  | bla.
  | [clinic start generated code]*/
  `

 to produce something like this:

 static PyObject *
 time_localtime(PyObject *self, PyObject *args)
 {
  PyObject *obj = NULL;
  time_t seconds;
  struct tm buf;

  if (!PyArg_ParseTuple(args, |O:localtime, obj))
  return NULL;
  if (obj == NULL || obj == Py_None)
  seconds = time(NULL);
  else {
  if (_PyTime_ObjectToTime_t(obj, seconds) == -1)
  return NULL;
  }
  return time_localtime_impl(self, seconds);
 }


 Apart from getting an error from clinic.py, it seems to me that this
 should in principle be possible.

 Best,
 Nikolaus


 
  So, the best idea is to
 
  * Remove the PyArgs_ParseTuple code from parse_time_t_args
  * Declare seconds as a plain object in Argument Clinic
  * Call the modified parse_time_t_args on seconds first thing in the _impl
  functions
 
 
  On Sat, Jan 18, 2014 at 4:56 PM, Nikolaus Rath nikol...@rath.org
 wrote:
 
  Hello,
 
  I'm trying to convert functions using parse_time_t_args() (from
  timemodule.c) for argument parsing to argument clinic.
 
  The function is defined as:
 
  ,
  | static int
  | parse_time_t_args(PyObject *args, char *format, time_t *pwhen)
  | {
  | PyObject *ot = NULL;
  | time_t whent;
  |
  | if (!PyArg_ParseTuple(args, format, ot))
  | return 0;
  | if (ot == NULL || ot == Py_None) {
  | whent = time(NULL);
  | }
  | else {
  | if (_PyTime_ObjectToTime_t(ot, whent) == -1)
  | return 0;
  | }
  | *pwhen = whent;
  | return 1;
  | }
  `
 
  and used like this:
 
  ,
  | static PyObject *
  | time_localtime(PyObject *self, PyObject *args)
  | {
  | time_t when;
  | struct tm buf;
  |
  | if (!parse_time_t_args(args, |O:localtime, when))
  | return NULL;
  | if (pylocaltime(when, buf) == -1)
  | return NULL;
  | return tmtotuple(buf);
  | }
  `
 
  In other words, if any Python object is passed to it, it calls
  _PyTime_ObjectToTime_t on it to convert it to time_t, and otherwise uses
  time(NULL) as the default value.
 
  May first attempt to implement something similar in argument clinic was:
 
  ,
  | /*[python input]
  | class time_t_converter(CConverter):
  | type = 'time_t'
  | converter = 'time_t_converter'
  | default = None
  | py_default = 'None'
  | c_default = 'time(NULL)'
  | converter = '_PyTime_ObjectToTime_t'
  | [python start generated code]*/
  |
  | /*[clinic input]
  | time.localtime
  |
  | seconds: time_t
  | /
  |
  | bla.
  | [clinic start generated code]*/
  `
 
  However, running clinic.py on this file gives:
 
  ,
  | $ Tools/clinic/clinic.py Modules/timemodule.c
  | Error in file Modules/timemodule.c on line 529:
  | Exception raised during parsing:
  | Traceback (most recent call last):
  |   File Tools/clinic/clinic.py, line 1445, in parse
  | parser.parse(block)
  |   File Tools/clinic/clinic.py, line 2738, in parse
  | self.state(None)
  |   File Tools/clinic

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

[Ryan Smith-Roberts]

Let me expand on the issue, and address some of the replies.

The goal of Argument Clinic is to create new docstring signatures for
builtins, with the following properties:

1) Useful. While one can create a signature of func(*args) and then
document complex and arbitrary restrictions on what args contains, that
isn't helpful to the end-user examining the docstring, or to automated
tools.

2) Inspectable. For a signature to be compatible with inspect.signature(),
it *must be a valid native Python declaration*. This means no optional
positional arguments of the form func(foo[, bar]), and no non-Python
default values.

3) Correct. The semantics of the builtin's signature should match the
expectations users have about pure Python declarations.

There are two classes of builtins whose signatures do not have these
properties. The first is those with very weird signatures, like
curses.window.addstr(). It's fine that those don't get converted, they're
hopeless. A second class is builtins with almost but not quite usable
signatures, mostly the ones with optional positional parameters. It would
be nice to rescue those builtins. So, let us return to my original
example, getservbyname(). Its current signature:

socket.getservbyname(servicename[, protocolname])

This is not an inspectable signature, since pure Python does not support
bracketed arguments. To make it inspectable, we must give protocolname a
(valid Python) default value:

socket.getservbyname(servicename, protocolname=None)

Unfortunately, while useful and inspectable, this signature is not correct.
For a pure Python function, passing None for protocolname is the same as
omitting it. However, if you pass None to getservbyname(), it raises a
TypeError. So, we have these three options:

1) Don't give getservbyname() an inspectable signature.
2) Lie to the user about the acceptability of None.
3) Alter the semantics of getservbyname() to treat None as equivalent to
omitting protocolname.

Obviously #2 is out. My question: is #3 ever acceptable? It's a real
change, as it breaks any code that relies on the TypeError exception.


___
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] AC Derby and accepting None for optional positional arguments

[Ryan Smith-Roberts]

One of the downsides of converting positional-only functions to Argument
Clinic is that it can result in misleading docstring signatures. Example:

socket.getservbyname(servicename[, protocolname])
-
socket.getservbyname(servicename, protocolname=None)

The problem with the new signature is that it indicates passing None for
protocolname is the same as omitting it (the other, much larger problem is
that it falsely indicates keyword compatibility, but that's a separate
indoor elephant).

My question:

Is it OK to change a longstanding function to treat None like an absent
parameter, where previously it was an error? (This also entails a docs
update and maybe a changelog entry)
___
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] AC Derby and accepting None for optional positional arguments

[Ryan Smith-Roberts]

On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts r...@lab.net wrote:

 socket.getservbyname(servicename[, protocolname])
 -
 socket.getservbyname(servicename, protocolname=None)


Here is a more complicated example, since the above does technically have
an alternative fix:

sockobj.sendmsg(buffers[, ancdata[, flags[, address]]])
-
sockobj.sendmsg(buffers, ancdata=None, flags=0, address=None)
___
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] Changing Clinic's output

[Ryan Smith-Roberts]

I favor a dual-mode approach. I think the existing behavior is best for the
conversion of existing modules, because it's easy to interactively verify
the generated code. Once that's done, long-term maintenance definitely
favors a more centralized format.

+1 _pickle.original.c /* used only during conversion of existing modules */
+0 _pickle.using-buffer.c
+1 _pickle.using-modified-buffer.c
-1  _pickle.using-multiple-buffers.c
NaN _pickle.using-sidefile.c /* not enough experience with it */

Pondering it this afternoon, I thought of a configuration that minimizes
both code churn and readability impact: two buffers. One at the top
containing forward declarations and defines (an inline header file if you
like), and the rest of the autogenerated code at the bottom. It's not
obvious that AC currently supports this configuration, or backtracking of
any kind. Nonetheless:

+1 _pickle.using-two-buffers.c


On Tue, Jan 14, 2014 at 12:22 PM, Larry Hastings la...@hastings.org wrote:


 On 01/11/2014 07:35 PM, Larry Hastings wrote:


 On 01/08/2014 07:08 AM, Barry Warsaw wrote:

 How hard would it be to put together some sample branches that provide
 concrete examples of the various options?

 My own opinion could easily be influenced by having some hands-on time with
 actual code, and I suspect even Guido could be influenced if he could pull
 some things up in his editor and take a look around.


 I've uploaded a prototype here:

 https://bitbucket.org/larry/python-clinic-buffer



 I have now received exactly zero feedback about the prototype, which
 suggests people aren't using it.  In an attempt to jump-start this
 conversation, I've created a new repository containing the concrete
 examples of the various options that Barry proposed above.  You may find
 it here:

 https://bitbucket.org/larry/clinic-buffer-samples/src

 In it I converted Modules/_pickle.c four different ways.  There's a
 README, please read it.

 People who want to change how Clinic writes its output: this is your big
 chance.  Comment on these samples, or produce your own counterexamples, or
 something.  If you can enough people on your side maybe Clinic will
 change.  If there is no further debate on this topic, nothing will happen
 and Clinic will not change.


 */arry*

 ___
 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/rmsr%40lab.net


___
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] Changing Clinic's output

[Ryan Smith-Roberts]

On Tue, Jan 14, 2014 at 5:32 PM, Ryan Smith-Roberts r...@lab.net wrote:

 NaN _pickle.using-sidefile.c /* not enough experience with it */


I hate to weasel like that. Intellectually I think I favor the sidefile
over all other approaches for its cleanliness. But I'd have to actively use
it in a workflow a bit to know how practical it is.
___
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