Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()
21.01.14 04:44, Nikolaus Rath написав(ла):
Serhiy Storchaka writes:
20.01.14 06:19, Nikolaus Rath написав(ла):
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?
/*[clinic input]
time.gmtime
[
seconds: time_t
]
/
Ahh, interesting. So this works, but now the C default is evaluated even
if the user passed an argument (so that answers my question about
decreased performance in the other subthread). The generated code is:
Don't use time(NULL) as C default. Instead check group_right_1 and call
time(NULL) explicitly.
time_gmtime_impl(PyModuleDef *module, int group_right_1, time_t seconds)
{
if (!group_right_1)
seconds = time(NULL);
...
}
___
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()
On 01/21/2014 12:59 AM, Serhiy Storchaka wrote: 21.01.14 04:44, Nikolaus Rath написав(ла): Serhiy Storchaka writes: 20.01.14 06:19, Nikolaus Rath написав(ла): 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? /*[clinic input] time.gmtime [ seconds: time_t ] / Ahh, interesting. So this works, but now the C default is evaluated even if the user passed an argument (so that answers my question about decreased performance in the other subthread). The generated code is: Don't use time(NULL) as C default. Instead check group_right_1 and call time(NULL) explicitly. While this "trick" works, it abuses optional groups. Optional groups are intended as a last resort, for semantics that can't be expressed any other way. The semantics of time.gmtime() are very easily expressed using normal Python syntax. Please don't use optional groups here. //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/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
On 21 Jan 2014 13:49, "Larry Hastings" wrote: > > On 01/20/2014 03:53 PM, Nick Coghlan wrote: >> >> Please turn the question around and look at it with your release manager hat on rather than your creator of Argument Clinic hat: if I came to you and said I wanted to add a new public API to the inspect module after the second beta release, what would you say? Can you honestly say that if *someone else* was proposing the inclusion of a new public API this late in the release cycle, you would say yes? > > > You're right. Optional group information won't be a public API in 3.4. Thanks for that. I agree it's a shame we missed the 3.4 feature deadline (as I would also like to see full C level signature support done and dusted), but once 3.4 is out the door we can hopefully resurrect PEP 457 as a direct successor to the original PEP 362, and update the inspect module to also handle these quirkier variants. Perhaps we can even add that public API for building Signature objects from string definitions, since that has proved quite handy internally :) Cheers, Nick. > > > /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/ncoghlan%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] Formatting of positional-only parameters in signatures
There is one more, hopefully last, open urgent question with the signature object. At the time we were working on the PEP 362, PEP 457 didn’t exist. Nor did we have any function with real positonal-only parameters, since there was no Argument Clinic yet. However, I implemented rudimentary support for them: “Parameter.POSITIONAL_ONLY” constant; “Signature.bind” and “Signature.bind_partial” fully support functions with positional-only parameters; “Signature.__str__” renders them distinctively from other kinds. The last point is the troublesome now. "Signature.__str__” renders positional-only parameters in ‘<>’ brackets, so in: foo(, , baz) “ham” and “spam” are positional-only. The choice of angle brackets was unfortunate, as, first of all, this wasn’t really discussed on python-dev, and second, it’s easy to think that those parameters are optional. Now, with the AC landing in 3.4, we need to decide how positional-only parameters will look like. Without starting a new discussion similar to what we had prior to PEP 457, I think we have three options: 1. Leave it as is. Obviously, the downside is the potential confusion with “optional” notation. 2. Adopt PEP 457 style: using “/“ to separate positional-only parameters from the rest. 3. Don’t use any notation, just render them as plain arguments: "foo(ham, spam, baz)". The downside here is that the users will be confused, and might try passing those parameters with keywords, or binding them with keywords. Thoughts? 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] PEP 461 updates
On Sun, Jan 19, 2014 at 7:21 AM, Oscar Benjamin
wrote:
> > long as numpy.loadtxt is explicitly documented as only working with
> > latin-1 encoded files (it currently isn't), there's no problem.
>
> Actually there is problem. If it explicitly specified the encoding as
> latin-1 when opening the file then it could document the fact that it
> works for latin-1 encoded files. However it actually uses the system
> default encoding to read the file
which is a really bad default -- oh well. Also, I don't think it was a
choice, at least not a well thought out one, but rather what fell out of
tryin gto make it "just work" on py3.
and then converts the strings to
> bytes with the as_bytes function that is hard-coded to use latin-1:
> https://github.com/numpy/numpy/blob/master/numpy/compat/py3k.py#L28
>
> So it only works if the system default encoding is latin-1 and the
> file content is white-space and newline compatible with latin-1.
> Regardless of whether the file itself is in utf-8 or latin-1 it will
> only work if the system default encoding is latin-1. I've never used a
> system that had latin-1 as the default encoding (unless you count
> cp1252 as latin-1).
>
even if it was a common default it would be a "bad idea". Fortunately (?),
so it really is broken, we can fix it without being too constrained by
backwards compatibility.
>
> > If it's supposed to work with other encodings (but the entire file is
> > still required to use a consistent encoding), then it just needs
> > encoding and errors arguments to fit the Python 3 text model (with
> > "latin-1" documented as the default encoding).
>
> This is the right solution. Have an encoding argument, document the
> fact that it will use the system default encoding if none is
> specified, and re-encode using the same encoding to fit any dtype='S'
> bytes column. This will then work for any encoding including the ones
> that aren't ASCII-compatible (e.g. utf-16).
>
Exactly, except I dont think the system encoding as a default is a good
choice. If there is a default MOST people will use it. And it will work for
a lot of their test code. Then it will break if the code is passed to a
system with a different default encoding, or a file comes from another
source in a different encoding. This is very, very likely. Far
more likely that files consistently being in the system encoding
> > default behaviour, since passing something like
> > codecs.getdecoder("utf-8") as a column converter should do the right
> > thing.
>
that seems to work at the moment, actually, if done with care.
That's just getting silly IMO. If the file uses mixed encodings then I
> don't consider it a valid "text file" and see no reason for loadtxt to
> support reading it.
agreed -- that's just getting crazy -- the only use-case I can image is to
clean up a file that got moji-baked by some other process -- not really the
use case for loadtxt and friends.
-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] Formatting of positional-only parameters in signatures
On 1/21/2014 10:59 AM, Yury Selivanov wrote: There is one more, hopefully last, open urgent question with the signature object. At the time we were working on the PEP 362, PEP 457 didn’t exist. Nor did we have any function with real positonal-only parameters, since there was no Argument Clinic yet. However, I implemented rudimentary support for them: “Parameter.POSITIONAL_ONLY” constant; “Signature.bind” and “Signature.bind_partial” fully support functions with positional-only parameters; “Signature.__str__” renders them distinctively from other kinds. The last point is the troublesome now. "Signature.__str__” renders positional-only parameters in ‘<>’ brackets, so in: foo(, , baz) This amounts to a hidden new API. “ham” and “spam” are positional-only. The choice of angle brackets was unfortunate, as, first of all, this wasn’t really discussed on python-dev, and second, it’s easy to think that those parameters are optional. Now, with the AC landing in 3.4, we need to decide how positional-only parameters will look like. Without starting a new discussion similar to what we had prior to PEP 457, I think we have three options: 1. Leave it as is. Obviously, the downside is the potential confusion with “optional” notation. I think this this is bad, as it has not been discussed and agreed on, and might be changed. It is a plausible alternative to '/', but might possibly even have been rejected. I do not remember. 2. Adopt PEP 457 style: using “/“ to separate positional-only parameters from the rest. I think this is what Larry proposed, but Nick opposed as a post-beta new feature. 3. Don’t use any notation, just render them as plain arguments: "foo(ham, spam, baz)". The downside here is that the users will be confused, and might try passing those parameters with keywords, or binding them with keywords. This is the status quo for the docs (both notation and occasional confusion). I think signature should match until we agree on a new convention (and I think one is needed). The first thing to decide is whether to mark each position-only parameter or to put one marker after all of them. -- Terry Jan Reedy ___ 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] Formatting of positional-only parameters in signatures
Terry, On January 21, 2014 at 12:23:31 PM, Terry Reedy (tjre...@udel.edu) wrote: > > On 1/21/2014 10:59 AM, Yury Selivanov wrote: > > There is one more, hopefully last, open urgent question with > the signature > > object. At the time we were working on the PEP 362, PEP 457 didn’t > > exist. Nor did we have any function with real positonal-only > parameters, > > since there was no Argument Clinic yet. However, I implemented > > rudimentary support for them: > > > > “Parameter.POSITIONAL_ONLY” constant; > > > > “Signature.bind” and “Signature.bind_partial” fully support > functions > > with positional-only parameters; > > > > “Signature.__str__” renders them distinctively from other > kinds. > > > > The last point is the troublesome now. "Signature.__str__” > renders > > positional-only parameters in ‘<>’ brackets, so in: > > > > foo(, , baz) > > This amounts to a hidden new API. Yes, and no. This wasn’t documented and until 3.4 we had no real-world positonal-only parameters. So I think it’s OK to fix this now. 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] Formatting of positional-only parameters in signatures
On 01/21/2014 07:59 AM, Yury Selivanov wrote: 2. Adopt PEP 457 style: using “/“ to separate positional-only parameters from the rest. +1 -- ~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] Formatting of positional-only parameters in signatures
On 22 Jan 2014 03:24, "Terry Reedy" wrote: > > On 1/21/2014 10:59 AM, Yury Selivanov wrote: >> >> There is one more, hopefully last, open urgent question with the signature >> object. At the time we were working on the PEP 362, PEP 457 didn’t >> exist. Nor did we have any function with real positonal-only parameters, >> since there was no Argument Clinic yet. However, I implemented >> rudimentary support for them: >> >> “Parameter.POSITIONAL_ONLY” constant; >> >> “Signature.bind” and “Signature.bind_partial” fully support functions >> with positional-only parameters; >> >> “Signature.__str__” renders them distinctively from other kinds. >> >> The last point is the troublesome now. "Signature.__str__” renders >> positional-only parameters in ‘<>’ brackets, so in: >> >> foo(, , baz) > > > This amounts to a hidden new API. > > >> “ham” and “spam” are positional-only. The choice of angle brackets was >> unfortunate, as, first of all, this wasn’t really discussed on >> python-dev, and second, it’s easy to think that those parameters are >> optional. >> >> Now, with the AC landing in 3.4, we need to decide how positional-only >> parameters will look like. >> >> Without starting a new discussion similar to what we had prior to PEP 457, >> I think we have three options: >> >> 1. Leave it as is. Obviously, the downside is the potential confusion >> with “optional” notation. > > > I think this this is bad, as it has not been discussed and agreed on, and might be changed. It is a plausible alternative to '/', but might possibly even have been rejected. I do not remember. It was the "we have to do something about this" short term fix we implemented for 3.3, that hasn't caused major problems due to the difficulties of creating such signatures in the first place. Argument Clinic changes that, since a variety of C level callables with this kind of signature will know be handled by the inspect module. I think it's actually tolerable to leave this in place for 3.4 as well, although I'd prefer to instead bring it into line with Argument Clinic. >> 2. Adopt PEP 457 style: using “/“ to separate positional-only parameters >> from the rest. > > > I think this is what Larry proposed, but Nick opposed as a post-beta new feature. No, I think this is a good idea. It matches previous discussions with Guido and is more consistent with Argument Clinic. The exchange between me and Larry was about the more exotic signatures like range() that inspect.Signature currently can't even represent internally - handling *those* requires changes to the data model and public API of inspect.Signature, not just the string representation. By contrast, positional only parameter support is already there, it's just that the notation used in the string representation is inconsistent with Argument Clinic's notation. >> 3. Don’t use any notation, just render them as plain arguments: >> "foo(ham, spam, baz)". The downside here is that the users will be >> confused, and might try passing those parameters with keywords, or >> binding them with keywords. > > > This is the status quo for the docs (both notation and occasional confusion). I think signature should match until we agree on a new convention We already rejected this option when inspect.Signature was first added. I don't see a good reason to reverse that decision now. > (and I think one is needed). The first thing to decide is whether to mark each position-only parameter or to put one marker after all of them. That's (at least in part) what PEP 457 was about - documenting the format Guido had already given lukewarm approval to. It's the basis of Argument Clinic's syntax, and currently illegal Python syntax. Cheers, Nick. > > -- > Terry Jan Reedy > > > > ___ > 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/ncoghlan%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] Using argument clinic to replace timemodule.c:parse_time_t_args()
Larry Hastings writes:
> A comment on your approach so far: I'm very much against giving
> "default" a default value in the constructor.
You mean in the definition of the custom converter class?
> I realize that hack saves you having to say "= NULL" in a lot of
> places. But explicit is better than implicit, and we're going to read
> these signatures a lot more often than we write them, and I want
> Clinic signatures to be easy to read at first glance.
[]
> All is not lost! What follows is rough pseudo-C code, hopefully you
> can take it from here.
>
>typedef struct {
> int set;
> time_t when;
>} clinic_time_t;
>#define DEFAULT_CLINIC_TIME_T {0, 0}
>
[...]
>
>/*[python input]
>class clinic_time_t_converter(CConverter):
> type = 'clinic_time_t'
> converter = 'parse_clinic_time_t'
> c_default = 'DEFAULT_CLINIC_TIME_T'
>[python start generated code]*/
>/*[python end generated code: checksum=...]*/
>
> Now you can use clinic_time_t. Parameters declared clinic_time_t can
> be required, or they can be optional; if they're optional give them a
> default value of None.
That doesn't work. If the default value is declared for the function
rather than in the converter definition, it overwrites the C default:
/*[clinic input]
time.gmtime
seconds: clinic_time_t=None
/
*/
gives:
static PyObject *
time_gmtime(PyModuleDef *module, PyObject *args)
{
PyObject *return_value = NULL;
clinic_time_t seconds = Py_None;
if (!PyArg_ParseTuple(args,
"|O&:gmtime",
parse_clinic_time_t, &seconds))
goto exit;
return_value = time_gmtime_impl(module, seconds);
so the default for seconds is now Py_None instead of
DEFAULT_CLINIC_TIME_T'.
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/archive%40mail-archive.com
Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()
Yes, I meant in the definition of the convertor class. You can fix c_default
in converter_init.
On Jan 21, 2014 7:19 PM, Nikolaus Rath wrote:
>
> Larry Hastings writes:
> > A comment on your approach so far: I'm very much against giving
> > "default" a default value in the constructor.
>
> You mean in the definition of the custom converter class?
>
> > I realize that hack saves you having to say "= NULL" in a lot of
> > places. But explicit is better than implicit, and we're going to read
> > these signatures a lot more often than we write them, and I want
> > Clinic signatures to be easy to read at first glance.
> []
> > All is not lost! What follows is rough pseudo-C code, hopefully you
> > can take it from here.
> >
> > typedef struct {
> > int set;
> > time_t when;
> > } clinic_time_t;
> > #define DEFAULT_CLINIC_TIME_T {0, 0}
> >
> [...]
> >
> > /*[python input]
> > class clinic_time_t_converter(CConverter):
> > type = 'clinic_time_t'
> > converter = 'parse_clinic_time_t'
> > c_default = 'DEFAULT_CLINIC_TIME_T'
> > [python start generated code]*/
> > /*[python end generated code: checksum=...]*/
> >
> > Now you can use clinic_time_t. Parameters declared clinic_time_t can
> > be required, or they can be optional; if they're optional give them a
> > default value of None.
>
> That doesn't work. If the default value is declared for the function
> rather than in the converter definition, it overwrites the C default:
>
> /*[clinic input]
> time.gmtime
>
> seconds: clinic_time_t=None
> /
> */
>
> gives:
>
> static PyObject *
> time_gmtime(PyModuleDef *module, PyObject *args)
> {
> PyObject *return_value = NULL;
> clinic_time_t seconds = Py_None;
>
> if (!PyArg_ParseTuple(args,
> "|O&:gmtime",
> parse_clinic_time_t, &seconds))
> goto exit;
> return_value = time_gmtime_impl(module, seconds);
>
> so the default for seconds is now Py_None instead of
> DEFAULT_CLINIC_TIME_T'.
>
> 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/larry%40hastings.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] Using argument clinic to replace timemodule.c:parse_time_t_args()
Larry Hastings writes:
> All is not lost! What follows is rough pseudo-C code, hopefully you
> can take it from here.
>
>typedef struct {
> int set;
> time_t when;
>} clinic_time_t;
>
>#define DEFAULT_CLINIC_TIME_T {0, 0}
>
>static int
>parse_clinic_time_t_arg(PyObject *arg, clinic_time_t *ct)
>{
> if (arg == NULL)
> return 1;
> if (arg == Py_None)
> return 0;
> if (_PyTime_ObjectToTime_t(arg, &ct->when) == -1) {
> set = 1;
> return 0;
> }
> return 1;
>}
>
>static int post_parse_clinic_time_t(clinic_time_t *ct) {
> if (ct->set)
> return 0;
> ct->when = time(NULL);
> return 0;
>}
>
>/*[python input]
>class clinic_time_t_converter(CConverter):
> type = 'clinic_time_t'
> converter = 'parse_clinic_time_t'
> c_default = 'DEFAULT_CLINIC_TIME_T'
>[python start generated code]*/
>/*[python end generated code: checksum=...]*/
>
> Now you can use clinic_time_t. Parameters declared clinic_time_t can
> be required, or they can be optional; if they're optional give them a
> default value of None. You'll have to call post_parse_clinic_time_t()
> by hand in your impl function; I'll see if I can extend Clinic so
> converters can emit code after a successful call to the parse function
> but before the call to the impl.
Okay, I attached a patch along these lines to the bugtracker.
However, I have to say that I lost track of what we're actually gaining
with all this. If all we need is a type that can distinguish between a
valid time_t value and a default value, why don't we simply use
PyObject?
In other words, what's the advantage of all the code above over:
static int
PyObject_to_time_t(PyObject *obj, time_t *when)
{
if (obj == NULL || obj == Py_None)
*when = time(NULL);
else if (_PyTime_ObjectToTime_t(obj, when) == -1)
return 0;
return 1;
}
/*[clinic input]
time.gmtime
seconds: object=NULL
/
[...]
static PyObject *
time_gmtime_impl(PyModuleDef *module, PyObject *seconds)
{
PyObject *return_value = NULL;
time_t when;
if(!PyObj_to_time_t(seconds, &when))
return NULL;
[...]
To me this version looks shorter and clearer. Is there really an
advantage in defining the clinic argument as a custom struct rather than
object?
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/archive%40mail-archive.com
Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()
22.01.14 07:13, Nikolaus Rath написав(ла): To me this version looks shorter and clearer. Is there really an advantage in defining the clinic argument as a custom struct rather than object? To me too. ___ 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
