After the latest Argument Clinic updates my patches began to look much better.
Thank you Larry. Now Argument Clinic supports output to side file (this is not
default, you should specify output preset file at the start of first clinic
declaration).
I already wrote about this here, but it seems
On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka storch...@gmail.com wrote:
2. I'm not use any IDE, but if you use, it can be important for you. If IDE
shows sources tree, unlikely you want to see generated *.clinic.c files in
them. This will increase the list of sources almost twice.
A point
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman et...@stoneleaf.us wrote:
PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a bit massaging:
On 18 Jan 2014 19:08, Chris Angelico ros...@gmail.com wrote:
On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka storch...@gmail.com
wrote:
2. I'm not use any IDE, but if you use, it can be important for you. If
IDE
shows sources tree, unlikely you want to see generated *.clinic.c files
in
On 18 Jan 2014 11:52, Ethan Furman et...@stoneleaf.us wrote:
On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote:
Overriding Principles
=
In order to avoid the problems of auto-conversion and Unicode
exceptions
On 17 January 2014 21:37, Chris Barker chris.bar...@noaa.gov wrote:
For the record, we've got a pretty good thread (not this good, though!) over
on the numpy list about how to untangle the mess that has resulted from
porting text-file-parsing code to py3 (and the underlying issue with the 'S'
Serhiy Storchaka storch...@gmail.com wrote:
Now generated files have suffixes .clinic.c. I think it will be better, if
they
will end at special suffix (.c.clinic or even just .clinic).
Can the output not go into a header file with static inline functions?
I'd rather see memoryview.h than
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah ste...@bytereef.org wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
memoryview_if.h // public interface
Antoine Pitrou solip...@pitrou.net wrote:
Objects/memoryview.clinic.h should be fine.
Last attempt:
Objects/memoryview.api.h
That is more neutral and describes what the file contains. IOW, it's easier to
ignore the name (which is good in this case).
Stefan Krah
On Sat, 18 Jan 2014 18:18:49 +0100
Stefan Krah ste...@bytereef.org wrote:
Antoine Pitrou solip...@pitrou.net wrote:
Objects/memoryview.clinic.h should be fine.
Last attempt:
Objects/memoryview.api.h
That is more neutral and describes what the file contains.
Disagreed. It's not
Antoine Pitrou solip...@pitrou.net wrote:
Objects/memoryview.api.h
That is more neutral and describes what the file contains.
Disagreed. It's not an API in the sense that it's something that's
designed to be called directly by third-party code.
Right. Objects/memoryview.ac.h
On 01/18/2014 03:40 AM, Antoine Pitrou wrote:
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman et...@stoneleaf.us wrote:
PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a
On 01/18/2014 05:28 AM, Nick Coghlan wrote:
However, if both Visual Studio and gdb can still find the symbols
correctly, even with the .clinic extension, then I would consider
that a point strongly in favour of Serhiy's suggestion.
No, that would be a lack of a point against Serhiy's
18.01.14 11:06, Chris Angelico написав(ла):
A point for the contrary side: In any editor or IDE with syntax
highlighting, a .clinic.c file will be highlighted as C code, but it
would take extra configuration to handle a .clinic file that way. But
that's a relatively minor consideration (AIUI
18.01.14 15:28, Nick Coghlan написав(ла):
I can argue either side, but the biggest potential problem I see with
Serhiy's suggestion is the likelihood of breaking automatic cross
referencing of symbols in most IDEs, as well as causing possible issues
for interactive debuggers. These are at least
18.01.14 19:39, Stefan Krah написав(ла):
Right. Objects/memoryview.ac.h perhaps? I sort of dislike reading full words
in filename extensions.
.ac is well known suffix of autoconf related files. And tail .h has same
disadvantages as .c.
___
18.01.14 19:09, Antoine Pitrou написав(ла):
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah ste...@bytereef.org wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
On Sat, Jan 18, 2014 at 12:10 PM, Serhiy Storchaka storch...@gmail.com wrote:
18.01.14 19:09, Antoine Pitrou написав(ла):
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah ste...@bytereef.org wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
Or, if this collides with Include/*,
On 01/18/2014 01:02 AM, Serhiy Storchaka wrote:
1. I very very often use global search in sources. It's my way of navigation
and it's my way of investigations. I don't want to get false results in
generated files. And it is much easy to specify mask '*.[ch]' or '*.c,*.h'
(depending on tool)
Serhiy Storchaka storch...@gmail.com wrote:
.ac is well known suffix of autoconf related files.
I know, but unless someone writes Objects/configure.c I think this won't be a
problem.
And tail .h has same disadvantages as .c.
I'm not strongly inconvenienced by those you listed.
Stefan Krah
On 01/18/2014 05:48 AM, Nick Coghlan wrote:
On 18 Jan 2014 11:52, Ethan Furman wrote:
I'll admit to being somewhat on the fence about %a.
It seems there are two possibilities with %a:
1) have it be ascii(repr(obj))
2) have it be str(obj).encode('ascii', 'strict')
This gets very close
On 2014-01-18, Stephen J. Turnbull wrote:
The above are descriptions of current behavior (ie, unchanged by PEPs
460, 461), and this:
[..]
is the content of this proposal, is that right?
The proposal is that -2 enables the following:
- %r as an alias for %a (i.e. calls ascii())
- %s will
On 18/01/2014 05:09 pm, Antoine Pitrou wrote:
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
memoryview_if.h // public interface
Objects/memoryview.clinic.h should be fine.
Or maybe have a __clinic__ directory similar to
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.
.inl is also sometimes used as an
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;
|
|
On 01/18/2014 10:49 AM, Larry Hastings wrote:
Later in the thread someone suggests that .h would be a better ending; I'm
willing to consider that.
I'll cast a vote for .clinic.h. :)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
Ethan Furman et...@stoneleaf.us wrote:
So, if %a is added it would act like:
-
%a % some_obj
-
tmp = str(some_obj)
res = b''
for ch in tmp:
if ord(ch) 256:
res += bytes([ord(ch)]
else:
res += unicode_escape(ch)
-
Steven D'Aprano st...@pearwood.info wrote:
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
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
Neil Schemenauer writes:
That's it. After sleeping on it, I'm not sure that's enough Python
2.x compatibility to help a lot. I haven't ported much code to 3.x
yet but I imagine the following are major challenges:
- comparisons between str and bytes always returns unequal
-
On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
Ethan Furman et...@stoneleaf.us wrote:
So, if %a is added it would act like:
-
%a % some_obj
-
tmp = str(some_obj)
res = b''
for ch in tmp:
if ord(ch) 256:
res += bytes([ord(ch)]
else:
On 01/18/2014 02:01 PM, Ethan Furman wrote:
where 'unicode_escape' would yield something like \u0440 ?
Just to be clear, \u0440 is the six bytes b'\\', b'u', b'0', b'4', b'4', b'0'.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
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
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
On 19 January 2014 00:39, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
If you want to draw a relevant lesson from that thread in this one
then the lesson argues against PEP 461: adding back the bytes
formatting methods helps people who refuse to understand text
processing and continue
On 19 January 2014 10:44, Steve Dower steve.do...@microsoft.com 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
On 19 January 2014 12:34, Ethan Furman et...@stoneleaf.us wrote:
On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
Ethan Furman et...@stoneleaf.us wrote:
So, if %a is added it would act like:
-
%a % some_obj
-
tmp = str(some_obj)
res = b''
for ch in tmp:
37 matches
Mail list logo
