Re: [Python-Dev] PEP 461 Final?
Ethan Furman writes: > > This argument is specious. > > I don't think so. I think it's a good argument for the future of > Python code. I agree that restricting bytes '%'-formatting to ASCII is a good idea, but you should base your arguments on a correct description of what's going on. It's not an issue of representability. It's an issue of "we should support this for ASCII because it's a useful, nearly universal convention, and we should not support ASCII supersets because that leads to mojibake." > Then you could have your text /and/ your numbers be in your own > language. My language uses numerals other than those in the ASCII repertoire in a rather stylized way. I can't use __format__ for that, because it depends on context, anyway. Most of the time the digits in the ASCII set are used (especially in tables and the like). I believe that's true for all languages nowadays. > Lots of features can be abused. That doesn't mean we shouldn't > talk about the intended use cases and encourage those. I only objected to claims that issues of "representability" and "what I can do with __format__" support the preferred use cases, not to descriptions of the preferred use cases. ___ 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 Final?
On 01/19/2014 06:56 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
Well, that means that this PEP just further strengthens the notion
that format is for text (as then a custom numeric type could easily
override the display even for :d, :h, etc.) and % is for bytes
(where such glyphs are not natively representable anyway).
This argument is specious.
I don't think so. I think it's a good argument for the future of Python code. Mind you, I should probably have said %
is primarily for bytes, or even more useful for bytes than for text. The idea being that true text fun stuff requires
format, while bytes can only use % for easy formatting.
Alternative numeric characters [are] just as representable as the ASCII
digits are, and in the same way (by defining a bytes <-> str mapping,
aka codec). The problem is not that they're non-representable, it's
that they're non-ASCII, and the numeric format codes implicitly
specify the ASCII numerals when in text as well as when in bytes.
Certainly. And you can't change that either. Oh, wait, you can! Define your
own!
class LocalNum(int):
"displays d, i, and u codes in local language"
def __format__(self, fmt):
# do the fancy stuff so the characters are not ASCII, but whatever
# is local here
Then you could have your text /and/ your numbers be in your own language. But you can't get that using % unless you
always call a custom function and use %s.
(Note
that "'{:d}'.format(True)" -> '1' works because True *is* an int and so
can be d-formatted in principle. It's not an exceptional case. It's
a different issue from what you're talking about here.)
"'{:d}'.format(True)" is not exceptional, you're right. But "'%d' % True" is, and was singled-out in the unicode
display code to print as '1' and not as 'True'. (Now all int subclasses behave this way (in 3.4 anyways).)
And I think it's the same issue, or at least closely related. If you create a custom number type with the intention of
displaying them in the local lingo, you have to use __format__ because % is hard coded to yield digits that map to ASCII.
These PEPs provide a crutch for such crippled software, allowing them
to hobble into the House of Python 3.
Very picturesque.
That's obvious, so please don't try to obfuscate it; just declare
"consenting adults" and move on.
Lots of features can be abused. That doesn't mean we shouldn't talk about the
intended use cases and encourage those.
--
~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] Using argument clinic to replace timemodule.c:parse_time_t_args()
Larry Hastings 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/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
Guido, Larry and I thrashed out the required semantics for parameter groups at PyCon US last year (and I believe the argument clinic PEP describes those accurately). They're mainly needed to represent oddball signatures like range() and slice(). However, I'm inclined to say that the affected functions should simply not support introspection until Python 3.5. It's not just a matter of the data model, there's also the matter of defining the string representation. Cheers, Nick. ___ 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 Final?
Ethan Furman writes:
> Well, that means that this PEP just further strengthens the notion
> that format is for text (as then a custom numeric type could easily
> override the display even for :d, :h, etc.) and % is for bytes
> (where such glyphs are not natively representable anyway).
This argument is specious.
Alternative numeric characters just as representable as the ASCII
digits are, and in the same way (by defining a bytes <-> str mapping,
aka codec). The problem is not that they're non-representable, it's
that they're non-ASCII, and the numeric format codes implicitly
specify the ASCII numerals when in text as well as when in bytes.
There's no technical reason why these features couldn't use EBCDIC or
even UTF-16 nowadays. It's purely a convention. But it's a very
useful convention, so it's helpful if Python conforms to it. (Note
that "{:d}.format(True)" -> '1' works because True *is* an int and so
can be d-formatted in principle. It's not an exceptional case. It's
a different issue from what you're talking about here.)
The problem that EIBTI worries about is that in many places there is a
local convention to use not pure ASCII, but a specific ASCII superset.
This allows them to take advantage of the common convention of using
ASCII for protocol keywords, and at the same time using "legacy"
facilities for internal processing of text. Becoming a disadvantage
if and when such programs need to communicate with internationalized
applications.
These PEPs provide a crutch for such crippled software, allowing them
to hobble into the House of Python 3. That's obvious, so please don't
try to obfuscate it; just declare "consenting adults" and move on.
___
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] signature.object, argument clinic and grouped parameters
In the midst of work on the issue #17481, it became apparent that we need a way of specifying optional/grouped parameters. One good example of grouped parameters in python is the `type` function. Basically, it has two different signatures: * type(name, bases, dict) * type(object) Which we can combine in one, if we define a notion of grouped parameters: * type(object_or_name, [bases, dict]) Another good example, is 'itertools.repeat'. Its signature is "(elem[, n])". If "n" argument is passed, then it's how many times the "elem" will be repeated, and if it is not passed at all, then "elem" will be repeated endlessly. One way of emulating this behavior in pure python is to define a special private marker object and use it as a default value: _optional = object() def repeat(elem, n=_optional): if n is _optional: # `n` wasn't passed, repeat indefinitely else: # we have something for `n` One of the problems with the above approach is how to represent its signature, how to document it clearly. Another one, is that there is no common marker, so whenever this is needed, a new marker is invented. Now, the more I think about having a concept of grouped parameters, the more different things to consider and take care of appear: * In issue #17481 Larry proposed that parameters will have a group id (arbitrary), and perhaps parent group id, to make it possible to have nested groups. * API for retrieving grouped parameters for the Signature objects. Something akin to what we have for ``regex.Match`` objects, probably. * An accepted and documented method of declaring groups for pure python function would be a nice thing to have. * Will we have groups for keyword-only parameters? Can we combine ``*args`` and a keyword-only parameter in a group? etc. That seems to be a lot of work (some of it is maybe enough for a PEP.) So before committing to the parameters groups idea, I'd like to propose somewhat simpler, but powerful enough to solve our todays problems solution. What if we add a notion of "optional" parameters? * ``Parameter.__init__ `` will receive one more keyword-only argument: ``optional``, ``False`` by default. * We add a special marker ``Parameter.optional`` (or some other name, like ``inspect.optional`` or ``functools.optional``), and teach ``inspect.signature`` to recognize it. So for pure-python functions, if you want to define an optional parameter, you would write: ``def mytype(name_or_obj, bases=Parameter.optional, dict=Parameter.optional)`` * Argument Clinic may get a new syntax for specifying if parameter is optional. * We standardize how optional parameters should look like in documentation and ``Signature.__str__``. In PEP 362 we used notation for optional parameters: ``foo(param=)``, but we also can use square brackets for that: ``bar([spam][, ham])``. With this approach, a signature of the ``type`` function would look like: ``type(object_or_name[, bases][, dict])``. The main downside is that it's not immediately apparent, that you can only pass either one argument "(object)", or all three arguments "(name, bases, dict)". But that's something, that a good documentation (and meaningful exceptions) could help with. The advantages if this approach, is that it works for all types of parameters, and that the implementation is going to be simpler than groups (and we will need fewer new APIs). 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 Final?
On 01/19/2014 03:37 AM, Steven D'Aprano wrote: On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote: On 01/17/2014 05:27 PM, Steven D'Aprano wrote: Numeric Format Codes To properly handle int and float subclasses, int(), index(), and float() will be called on the objects intended for (d, i, u), (b, o, x, X), and (e, E, f, F, g, G). -1 on this idea. I went to add examples to this section of the PEP, and realized I was just describing what Python does anyway. So it doesn't need to be in the PEP. -- ~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] Using argument clinic to replace timemodule.c:parse_time_t_args()
Larry Hastings 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. I don't see how the conversion would result in more calls to time() than we have now. It seems to me that the expression for the C default should be only evaluated if the caller did not specify a value. Is that not how ac works? > 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? As long as you're comfortable looking over the (probably buggy) patch, yes, I'm happy to give it a shot. 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()
On Sun, Jan 19, 2014 at 2:38 AM, Larry Hastings 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] PEP 461 Final?
On 01/19/2014 03:37 AM, Steven D'Aprano wrote: On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote: On 01/17/2014 05:27 PM, Steven D'Aprano wrote: Numeric Format Codes To properly handle int and float subclasses, int(), index(), and float() will be called on the objects intended for (d, i, u), (b, o, x, X), and (e, E, f, F, g, G). -1 on this idea. This is a rather large violation of the principle of least surprise, and radically different from the behaviour of Python 3 str. In Python 3, '%d' interpolation calls the __str__ method, so if you subclass, you can get the behaviour you want: Did you read the bug reports I linked to? This behavior (which is a bug) has already been fixed for Python3.4. No I didn't. This thread is huge, and it's only one of a number of huge threads about the same "bytes/unicode Python 2/3" stuff. I'm probably not the only person who missed the bug reports you linked to. Fair point. If these bug reports are relevant to the PEP, you ought to list them in the PEP, and if they aren't relevant, I shan't be reading them *wink* Well, it seems to me they are more relevant to your misunderstanding of how %d and friends should work rather than to the PEP itself. However, I suppose it possible you're not the only one so affected, so I'll link them in. In any case, whether I have succeeded in making the case against this aspect of the PEP or not Not. This was a bug that was fixed long before the PEP came into existence. As a quick thought experiment, why does "%d" % True return "1"? I don't know. Perhaps it is a bug? To summarize a rather long issue, %d and friends are /numeric/ codes; returning non-numeric text is inappropriate. Yes, I realize there are other unicode values than also mean numeric digits, but they do not mean (so far as I know) Decimal digits, or Hexadecimal digits, or Octal digits. (Obviously an ASCII slant going on there.) Now that I've written that down, I think there are, in fact, other scripts that represent a base-10 number system with obviously different glyphs for the numbers Well, that means that this PEP just further strengthens the notion that format is for text (as then a custom numeric type could easily override the display even for :d, :h, etc.) and % is for bytes (where such glyphs are not natively representable anyway). -- ~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] .clinic.c vs .c.clinic
On 01/19/2014 06:35 AM, Serhiy Storchaka wrote: 18.01.14 18:30, Eric V. Smith написав(ла): Same here. There's some history for this, but not for generated code. In Objects/stringlib, all of the files are .h files. They're really C code designed to be included by other .c files. Objects/stringlib files are hand-written. We should distinguish generated code from hand-written. We do. Generated files have .clinic. in the name. That is sufficient. -- ~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] .clinic.c vs .c.clinic
On 01/19/2014 03:32 AM, Georg Brandl wrote:
Am 19.01.2014 11:19, schrieb Larry Hastings:
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower wrote:
Visual Studio will try to compile them if they end with .c, though this can
be disabled on a per-file basis in the project file. Files ending in .h
won't be compiled, though changes should be detected and cause the .c files
that include them to be recompiled.
That sounds like a rather good argument for .clinic.h over .clinic.c :)
My assessment of the thread is that .clinic.h will give us the best
overall tool compatibility.
Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h".
But there's one onion in the ointment: what should "foo.h" generate? The day
may yet arrive when we have Argument Clinic code in foo.{ch}.
Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory?
Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h
Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
At least that is consistent, allows easy exclusion in tools, and gets rid
of the additional "clinic" in the filename.
+1
If AC will work with both .c and .h files. I think a separate directory is the
way to go.
--
~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] PEP 461 updates
On 19 January 2014 06:19, Nick Coghlan wrote:
>
> While I agree it's not relevant to the PEP 460/461 discussions, so
> 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 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).
> 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).
Then instead of having a compat module with an as_bytes helper to get
rid of all the unicode strings on Python 3, you can have a compat
module with an open_unicode helper to do the right thing on Python 2.
The as_bytes function is just a way of fighting the Python 3 text
model: "I don't care about mojibake just do whatever it takes to shut
up the interpreter and its error messages and make sure it works for
ASCII data."
> If it is intended to
> allow S columns to contain text in arbitrary encodings, then that
> should also be supported by the current API with an adjustment to the
> default behaviour, since passing something like
> codecs.getdecoder("utf-8") as a column converter should do the right
> thing. However, if you're currently decoding S columns with latin-1
> *before* passing the value to the converter, then you'll need to use a
> WSGI style decoding dance instead:
>
> def fix_encoding(text):
> return text.encode("latin-1").decode("utf-8") # For example
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.
> That's more wasteful than just passing the raw bytes through for
> decoding, but is the simplest backwards compatible option if you're
> doing latin-1 decoding already.
>
> If different rows in the *same* column are allowed to have different
> encodings, then that's not a valid use of the operation (since the
> column converter has no access to the rest of the row to determine
> what encoding should be used for the decode operation).
Ditto.
Oscar
___
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] .clinic.c vs .c.clinic
18.01.14 18:30, Eric V. Smith написав(ла): Same here. There's some history for this, but not for generated code. In Objects/stringlib, all of the files are .h files. They're really C code designed to be included by other .c files. Objects/stringlib files are hand-written. We should distinguish generated code from hand-written. ___ 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 Final?
On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote: > On 01/17/2014 05:27 PM, Steven D'Aprano wrote: > >>Numeric Format Codes > >> > >> > >>To properly handle int and float subclasses, int(), index(), and float() > >>will be called on the objects intended for (d, i, u), (b, o, x, X), and > >>(e, E, f, F, g, G). > > > > > >-1 on this idea. > > > >This is a rather large violation of the principle of least surprise, and > >radically different from the behaviour of Python 3 str. In Python 3, > >'%d' interpolation calls the __str__ method, so if you subclass, you can > >get the behaviour you want: > > Did you read the bug reports I linked to? This behavior (which is a bug) > has already been fixed for Python3.4. No I didn't. This thread is huge, and it's only one of a number of huge threads about the same "bytes/unicode Python 2/3" stuff. I'm probably not the only person who missed the bug reports you linked to. If these bug reports are relevant to the PEP, you ought to list them in the PEP, and if they aren't relevant, I shan't be reading them *wink* In any case, whether I have succeeded in making the case against this aspect of the PEP or not, I think you should: - explain what you mean by "properly handle" (give an example?); - justify why b'%d' % obj should ignore any relevant overloaded methods in obj; - if there are similar, existing, examples of this (to me) surprising behaviour, you should briefly mention them; - note that there was some opposition to the suggestion; - and explain why the contrary behaviour (i.e. allowing obj to overload b'%d') is not desirable. > As a quick thought experiment, why does "%d" % True return "1"? I don't know. Perhaps it is a bug? -- Steven ___ 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] .clinic.c vs .c.clinic
Am 19.01.2014 11:19, schrieb Larry Hastings:
> On 01/18/2014 10:36 PM, Nick Coghlan wrote:
>> On 19 January 2014 10:44, Steve Dower wrote:
>>> Visual Studio will try to compile them if they end with .c, though this can
>>> be disabled on a per-file basis in the project file. Files ending in .h
>>> won't be compiled, though changes should be detected and cause the .c files
>>> that include them to be recompiled.
>> That sounds like a rather good argument for .clinic.h over .clinic.c :)
>>
>> My assessment of the thread is that .clinic.h will give us the best
>> overall tool compatibility.
>
> Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h".
>
> But there's one onion in the ointment: what should "foo.h" generate? The day
> may yet arrive when we have Argument Clinic code in foo.{ch}.
>
> Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory?
Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h
Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
At least that is consistent, allows easy exclusion in tools, and gets rid
of the additional "clinic" in the filename.
Georg
___
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/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? 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. According to the issue tracker, " rmsr" has only ever filed one issue. I just fixed (and closed) it. //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] .clinic.c vs .c.clinic
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower wrote:
Visual Studio will try to compile them if they end with .c, though this can
be disabled on a per-file basis in the project file. Files ending in .h
won't be compiled, though changes should be detected and cause the .c files
that include them to be recompiled.
That sounds like a rather good argument for .clinic.h over .clinic.c :)
My assessment of the thread is that .clinic.h will give us the best
overall tool compatibility.
Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h".
But there's one onion in the ointment: what should "foo.h" generate?
The day may yet arrive when we have Argument Clinic code in foo.{ch}.
Not kidding, my best idea so far is "foo.clinic.h.h",
//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
