On 15 June 2013 11:54, Victor Stinner wrote:
> 2013/6/15 Antoine Pitrou :
>>> http://hg.python.org/cpython/rev/6661a8154eb3
>>> ...
>>> Issue #3329: Add new APIs to customize memory allocators
>>>
>>> * Add a new PyMemAllocators structure
>>> * New functions:
>>>
>>> - PyMem_RawMalloc(), PyMem
On 15 June 2013 14:08, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> Not a bug. The same is done for file input -- CRLF is changed to LF before
>> tokenizing.
>
>
> I'm not convinced it's reasonable behaviour to re-scan the
> string as though it's being read from a file. It's a Python
> string
On 15 June 2013 03:34, Antoine Pitrou wrote:
> On Wed, 5 Jun 2013 09:10:54 -0700
> Benjamin Peterson wrote:
>> I (and Guido) are accepting PEP 442 (Safe object finalization) on the
>> condition that finalizers are only ever called once globally.
>
> Ok, so there's an issue with that condition: it
Guido van Rossum wrote:
Not a bug. The same is done for file input -- CRLF is changed to LF
before tokenizing.
I'm not convinced it's reasonable behaviour to re-scan the
string as though it's being read from a file. It's a Python
string, so it's already been through whatever line-ending
transfo
2013/6/15 Antoine Pitrou :
>> http://hg.python.org/cpython/rev/6661a8154eb3
>> ...
>> Issue #3329: Add new APIs to customize memory allocators
>>
>> * Add a new PyMemAllocators structure
>> * New functions:
>>
>> - PyMem_RawMalloc(), PyMem_RawRealloc(), PyMem_RawFree(): GIL-free memory
>> a
On Sat, 15 Jun 2013 00:44:11 +0200 (CEST)
victor.stinner wrote:
> http://hg.python.org/cpython/rev/6661a8154eb3
> changeset: 84127:6661a8154eb3
> user:Victor Stinner
> date:Sat Jun 15 00:37:46 2013 +0200
> summary:
> Issue #3329: Add new APIs to customize memory allocators
>
I commited the new API (little bit different than my last patch on issue #3329):
http://hg.python.org/cpython/rev/6661a8154eb3
The documentation will be available in a few minutes at:
http://docs.python.org/3/c-api/memory.html
2013/6/14 Kristján Valur Jónsson :
>> Removing the GIL restriction wou
Ethan, did you forget to run ``hg add`` before committing? If not then why
the heck did we argue over enums for so long if this was all it took to
make everyone happy? =)
On Fri, Jun 14, 2013 at 3:31 AM, ethan.furman wrote:
> http://hg.python.org/cpython/rev/fae92309c3be
> changeset: 84117:fae
On 2013-06-14 23:31, Robert Kern wrote:
On 2013-06-14 21:55, R. David Murray wrote:
On Fri, 14 Jun 2013 21:12:00 +0200, Martin Schultz wrote:
2. Testing for empty lists or empty ndarrays:
In principle, `len(x) == 0` will do the trick. **BUT** there are several
caveats here:
- `len(scala
On 2013-06-14 21:55, R. David Murray wrote:
On Fri, 14 Jun 2013 21:12:00 +0200, Martin Schultz wrote:
2. Testing for empty lists or empty ndarrays:
In principle, `len(x) == 0` will do the trick. **BUT** there are several
caveats here:
- `len(scalar)` raises a TypeError, so you will have
On Fri, Jun 14, 2013 at 2:11 PM, Ron Adam wrote:
>
>
> On 06/14/2013 10:36 AM, Guido van Rossum wrote:
>>
>> Not a bug. The same is done for file input -- CRLF is changed to LF before
>> tokenizing.
>
>
>
> Should this be the same?
>
>
> python3 -c 'print(bytes("""\r\n""", "utf8"))'
> b'\r\n'
>
>
On Fri, 14 Jun 2013 21:12:00 +0200, Martin Schultz wrote:
> 2. Testing for empty lists or empty ndarrays:
>
> In principle, `len(x) == 0` will do the trick. **BUT** there are several
> caveats here:
>- `len(scalar)` raises a TypeError, so you will have to use try and
> except or find some ot
On 2013-06-14 21:03, Brett Cannon wrote:
On Fri, Jun 14, 2013 at 3:12 PM, Martin Schultz mailto:masch...@gmail.com>> wrote:
- add a `size` attribute to all objects (I wouldn't mind if this is None
in case you don't really know how to define the size of something, but it
would be
On Fri, Jun 14, 2013 at 3:12 PM, Martin Schultz wrote:
> As much as I love python, the following drives me crazy, and I would wish
> that some future version would come up with a more consistent approach for
> this. And please don't reply with "Too bad if you don't know what type your
> data are.
As much as I love python, the following drives me crazy, and I would wish
that some future version would come up with a more consistent approach for
this. And please don't reply with "Too bad if you don't know what type your
data are..." - if I want to implement some generic functionality, I want t
On 06/14/2013 10:36 AM, Guido van Rossum wrote:
Not a bug. The same is done for file input -- CRLF is changed to LF before
tokenizing.
Should this be the same?
python3 -c 'print(bytes("""\r\n""", "utf8"))'
b'\r\n'
>>> eval('print(bytes("""\r\n""", "utf8"))')
b'\n'
Ron
On Jun 14, 2
On Fri, 14 Jun 2013 19:34:41 +0200
Antoine Pitrou wrote:
> On Wed, 5 Jun 2013 09:10:54 -0700
> Benjamin Peterson wrote:
> > I (and Guido) are accepting PEP 442 (Safe object finalization) on the
> > condition that finalizers are only ever called once globally.
>
> Ok, so there's an issue with tha
On Wed, 5 Jun 2013 09:10:54 -0700
Benjamin Peterson wrote:
> I (and Guido) are accepting PEP 442 (Safe object finalization) on the
> condition that finalizers are only ever called once globally.
Ok, so there's an issue with that condition: it can't be upholded on
non-GC objects. Creating a non-GC
On Fri, 14 Jun 2013, R. David Murray wrote:
This discussion is better suited for python-ideas than it
is for python-dev.
Better yet, perl-ideas.
On Fri, 14 Jun 2013 16:50:53 +0200, Markus Unterwaditzer
wrote:
But why?
-- Markus (from phone)
Pynix Wang wrote:
1.lambda expression
c#
a.
ACTIVITY SUMMARY (2013-06-07 - 2013-06-14)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4042 (+18)
closed 25946 (+41)
total 29988 (+59)
Open issues wit
Not a bug. The same is done for file input -- CRLF is changed to LF before
tokenizing.
On Jun 14, 2013 8:27 AM, "Walter Dörwald" wrote:
> Hello all!
>
> This surprised me:
>
>>>> eval("'''\r\n'''")
>'\n'
>
> Where did the \r go? ast.literal_eval() has the same problem:
>
>>>> ast.lite
Hello all!
This surprised me:
>>> eval("'''\r\n'''")
'\n'
Where did the \r go? ast.literal_eval() has the same problem:
>>> ast.literal_eval("'''\r\n'''")
'\n'
Is this a bug/worth fixing?
Servus,
Walter
___
Python-Dev mailing list
Py
This discussion is better suited for python-ideas than it
is for python-dev.
On Fri, 14 Jun 2013 16:50:53 +0200, Markus Unterwaditzer
wrote:
> But why?
>
> -- Markus (from phone)
>
> Pynix Wang wrote:
> >1.lambda expression
> >
> >c#
> >a.(x, y) => x == y
> >b.() => SomeMethod()
> >
> >ruby:
But why?
-- Markus (from phone)
Pynix Wang wrote:
>1.lambda expression
>
>c#
>a.(x, y) => x == y
>b.() => SomeMethod()
>
>ruby:
> -> {|msg| puts msg}
>
>python can use c# like and remove "lambda" keyword.
>
>2.global variable
>
>ruby
>$glo_var
>
>python can use $ or @ or another and remove "glob
1.lambda expression
c#
a.(x, y) => x == y
b.() => SomeMethod()
ruby:
-> {|msg| puts msg}
python can use c# like and remove "lambda" keyword.
2.global variable
ruby
$glo_var
python can use $ or @ or another and remove "global".
___
Python-Dev mailin
14.06.13 04:18, brett.cannon написав(ла):
http://hg.python.org/cpython/rev/af27c661d4fb
changeset: 84115:af27c661d4fb
user:Brett Cannon
date:Thu Jun 13 21:18:43 2013 -0400
summary:
Move test_pep352 over to unittest.main()
You forgot about:
from test.support import run_uni
14.06.13 11:46, Antoine Pitrou написав(ла):
On Fri, 14 Jun 2013 07:06:49 +0200 (CEST)
raymond.hettinger wrote:
http://hg.python.org/cpython/rev/5accb0ac8bfb
changeset: 84116:5accb0ac8bfb
Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
computations.
Is there any
> -Original Message-
> I would like to remove the "GIL must be held" restriction from
> PyMem_Malloc(). In my opinion, the restriction was motived by a bug in
> Python, bug fixed by the issue #3329. Let me explain why.
>
...
>
> Removing the GIL restriction would help to replace direct
On Fri, 14 Jun 2013 07:06:49 +0200 (CEST)
raymond.hettinger wrote:
> http://hg.python.org/cpython/rev/5accb0ac8bfb
> changeset: 84116:5accb0ac8bfb
> branch: 2.7
> parent: 84095:ca8e86711403
> user:Raymond Hettinger
> date:Fri Jun 14 01:06:33 2013 -0400
> summary:
> F
29 matches
Mail list logo
