On 01/18/2014 10:36 PM, Nick Coghlan wrote:
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
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
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 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
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,
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
On 19 January 2014 06:19, Nick Coghlan ncogh...@gmail.com 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
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 steve.do...@microsoft.com wrote:
Visual Studio will try to compile them if they end with .c, though this can
be disabled
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.
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
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo
