On 19 January 2014 12:34, Ethan Furman wrote:
> On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
>>
>> Ethan Furman wrote:
>>>
>>> So, if %a is added it would act like:
>>>
>>> -
>>> "%a" % some_obj
>>> -
>>> tmp = str(some_obj)
>>> res = b''
>>> for ch in tmp:
>>>
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
On 19 January 2014 00:39, Oscar Benjamin 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 implementing dirty hacks
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
Hi Ryan,
Ryan Smith-Roberts 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_ar
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
ht
On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
Ethan Furman 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
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
>
> -
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
suppl
Steven D'Aprano 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 surprise, and
Ethan Furman 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)
> -
>
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
ht
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;
|
|
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 e
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 __pycache__.
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 wil
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
Serhiy Storchaka 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 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) tha
On Sat, Jan 18, 2014 at 12:10 PM, Serhiy Storchaka wrote:
> 18.01.14 19:09, Antoine Pitrou написав(ла):
>
>> On Sat, 18 Jan 2014 18:06:06 +0100
>> Stefan Krah wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
>>>
>>>
>>> Or, if this collides with Include/*, one of the followi
18.01.14 19:09, Antoine Pitrou написав(ла):
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah 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 interf
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.
___
Pytho
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 v
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 most
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 sug
On 01/18/2014 03:40 AM, Antoine Pitrou wrote:
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman wrote:
PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a bit massaging:
http:/
Antoine Pitrou 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 perhaps? I
On Sat, 18 Jan 2014 18:18:49 +0100
Stefan Krah wrote:
> Antoine Pitrou 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 an API in the sense that it's
Antoine Pitrou 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:06:06 +0100
Stefan Krah 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
Objects/memoryview.clinic.h s
> 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
Stefan Krah
___
Python-Dev mailing list
Python-Dev
On 1/18/2014 11:24 AM, Stefan Krah wrote:
> Serhiy Storchaka 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?
>
Serhiy Storchaka 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 memoryview.clinic.c
On 17 January 2014 21:37, Chris Barker 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'
> data type in num
On 18 Jan 2014 11:52, "Ethan Furman" 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
>>> e
On 18 Jan 2014 19:08, "Chris Angelico" wrote:
>
> On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka
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 th
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman wrote:
>
> PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a bit massaging:
http://www.python.org/dev/peps/pep-0461/
> .. note:
On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka 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 for the contrary
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
39 matches
Mail list logo
