Hi Guido,
On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum wrote:
> Sounds a bit like some security researchers drumming up business. If you can
> run the binary, presumably you can also recover the seed by looking in
> /proc, right? Or use ctypes or something. This demonstration seems of
> acad
On Thu, Oct 3, 2013 at 1:06 PM, Victor Stinner wrote:
> 2013/10/3 Christian Heimes :
> > A hash algorithm can be added and one avaible hash
> > algorithm can be set before Py_Initialize() is called for the first
> > time.
>
> "Py_Initialize" is not the good guard. Try for example "python3 -X
> fau
On Thu, Oct 3, 2013 at 12:05 PM, Guido van Rossum wrote:
> We already have adopted a feature that plugged most viable attacks on web
> apps, I think that's enough.
>
Actually... we did not do a very good job on that:
http://bugs.python.org/issue14621
The point of allowing alternates is to let p
On Thu, Oct 3, 2013 at 11:42 AM, Christian Heimes wrote:
> Hi,
>
> some of you may have seen that I'm working on a PEP for a new hash API
> and new algorithms for hashing of bytes and str. The PEP has three major
> aspects. It introduces DJB's SipHash as secure hash algorithm, chances
> the hash A
Igor Vasilyev wrote:
class A():
def __add__(self, var):
print("I'm in A class")
return 5
a = A()
a+1
1+a
Execution:
python test.py
I'm in A class
Traceback (most recent call last):
File "../../test.py", line 7, in
1+a
TypeError: unsupported operand type(s) for +: 'int
03.10.13 23:47, Guido van Rossum написав(ла):
On Thu, Oct 3, 2013 at 12:55 PM, Christian Heimes mailto:christ...@python.org>> wrote:
Am 03.10.2013 21:45, schrieb Guido van Rossum:
> But fixing that shouldn't need all the extra stuff you're
> proposing.
I have proposed some of
On Thu, Oct 3, 2013 at 2:13 PM, Nick Coghlan wrote:
> On 4 Oct 2013 06:08, "Victor Stinner" wrote:
> >
> > 2013/10/3 Christian Heimes :
> > > A hash algorithm can be added and one avaible hash
> > > algorithm can be set before Py_Initialize() is called for the first
> > > time.
> >
> > "Py_Initi
On 4 Oct 2013 06:08, "Victor Stinner" wrote:
>
> 2013/10/3 Christian Heimes :
> > A hash algorithm can be added and one avaible hash
> > algorithm can be set before Py_Initialize() is called for the first
> > time.
>
> "Py_Initialize" is not the good guard. Try for example "python3 -X
> faulthandl
Am 03.10.2013 21:53, schrieb Serhiy Storchaka:
>> the first time time with a bit shift of 7
>
> Double "time".
thx, fixed
>> with a 128bit seed and 64-bit output
>
> Inconsistancy with hyphen. There are same issues in other places.
I have unified the use of hyphens, thx!
>> bytes_hash provide
On Thu, Oct 3, 2013 at 12:55 PM, Christian Heimes wrote:
> Am 03.10.2013 21:45, schrieb Guido van Rossum:
> > But fixing that shouldn't need all the extra stuff you're
> > proposing.
>
> I have proposed some of the extra stuff for more flexibility, the rest
> is for testing and debugging.
>
Hm, I
On Thu, Oct 3, 2013 at 2:21 PM, Barry Warsaw wrote:
> PPProbably not the typppo Andrew was pppointing out.
>
> -Bary
Ohhh, that typppo.
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
On Oct 03, 2013, at 02:08 PM, Eric Snow wrote:
>On Thu, Oct 3, 2013 at 1:57 PM, A.M. Kuchling wrote:
>> On Thu, Oct 03, 2013 at 08:48:47PM +0200, eric.snow wrote:
>>> -- Issue #19951: Fix docstring and use of _get_suppported_file_loaders() to
>>> +- Issue #19151: Fix docstring and use of _get_sup
On Thu, Oct 3, 2013 at 1:57 PM, A.M. Kuchling wrote:
> On Thu, Oct 03, 2013 at 08:48:47PM +0200, eric.snow wrote:
>> -- Issue #19951: Fix docstring and use of _get_suppported_file_loaders() to
>> +- Issue #19151: Fix docstring and use of _get_suppported_file_loaders() to
>
2013/10/3 Christian Heimes :
> A hash algorithm can be added and one avaible hash
> algorithm can be set before Py_Initialize() is called for the first
> time.
"Py_Initialize" is not the good guard. Try for example "python3 -X
faulthandler": PyObject_Hash() is called before Py_Initialize() to add
On Thu, Oct 03, 2013 at 08:48:47PM +0200, eric.snow wrote:
> -- Issue #19951: Fix docstring and use of _get_suppported_file_loaders() to
> +- Issue #19151: Fix docstring and use of _get_suppported_file_loaders() to
^^^ likely a typo?
--amk
___
Am 03.10.2013 21:45, schrieb Guido van Rossum:
> But fixing that shouldn't need all the extra stuff you're
> proposing.
I have proposed some of the extra stuff for more flexibility, the rest
is for testing and debugging.
> What's a Python randomization key?
Python's hash randomization key, the s
Just some comments.
> the first time time with a bit shift of 7
Double "time".
> with a 128bit seed and 64-bit output
Inconsistancy with hyphen. There are same issues in other places.
> bytes_hash provides the tp_hash slot function for unicode.
Typo. Should be "unicode_hash".
> len = PyUnic
On Thu, Oct 3, 2013 at 12:23 PM, Christian Heimes wrote:
> Am 03.10.2013 21:05, schrieb Guido van Rossum:
> > Hm. I would like to stick to the philosophy that Python's hash
> > should be as fast as it possibly can be, and should not be mistaken
> > for a cryptographic hash. The point is to optimiz
Am 03.10.2013 21:05, schrieb Guido van Rossum:
> Hm. I would like to stick to the philosophy that Python's hash
> should be as fast as it possibly can be, and should not be mistaken
> for a cryptographic hash. The point is to optimize dict lookups,
> nothing more, given typical (or even atypical) k
Hm. I would like to stick to the philosophy that Python's hash should be as
fast as it possibly can be, and should not be mistaken for a cryptographic
hash. The point is to optimize dict lookups, nothing more, given typical
(or even atypical) key distribution, not to thwart deliberate attacks. We
a
On Thu, 03 Oct 2013 20:42:28 +0200
Christian Heimes wrote:
>
> I haven't actually benchmarked how a faster hash algorithm
> affects the a real program, though ...
Chances are it doesn't. Only a "slow enough" hash algorithm might have
an impact, IMHO.
> On which level should Python support a plu
Hi,
some of you may have seen that I'm working on a PEP for a new hash API
and new algorithms for hashing of bytes and str. The PEP has three major
aspects. It introduces DJB's SipHash as secure hash algorithm, chances
the hash API to process blocks of data instead characters and it adds an
API to
This list is for development OF Python, not for development in python. For
that reason, I will redirect this to python-list as well. My actual answer
is below.
On Thu, Oct 3, 2013 at 6:45 AM, Igor Vasilyev
wrote:
> Hi.
>
> Example test.py:
>
> class A():
> def __add__(self, var):
>
On 2013-10-03, at 15:45 , Igor Vasilyev wrote:
> Hi.
>
> Example test.py:
>
> class A():
>def __add__(self, var):
>print("I'm in A class")
>return 5
> a = A()
> a+1
> 1+a
>
> Execution:
> python test.py
> I'm in A class
> Traceback (most recent call last):
> File "../../te
On Thu, Oct 3, 2013 at 11:09 PM, Игорь Васильев wrote:
> When we adding class to integer we have both slotv and slotw. x = slotv(v,
> w); -> returns Py_NotImplemented.
> But in this case we should execute x = slotw(v, w); and function should be
> completed in the same way as when we adding integer
Hi,
I worked on the implementation of the tracemalloc module and its PEP
454. I consider that this third version of the PEP is ready for a
final review.
What should be done to finish the PEP?
HTML version of the PEP 454:
http://www.python.org/dev/peps/pep-0454/
Full documentation of the tracema
Hi.
Example test.py:
class A():
def __add__(self, var):
print("I'm in A class")
return 5
a = A()
a+1
1+a
Execution:
python test.py
I'm in A class
Traceback (most recent call last):
File "../../test.py", line 7, in
1+a
TypeError: unsupported operand type(s) for +: 'in
Hi.
Example test.py:
class A():
def __add__(self, var):
print("I'm in A class")
return 5
a = A()
a+1
1+a
Execution:
python test.py
I'm in A class
Traceback (most recent call last):
File "../../test.py", line 7, in
1+a
TypeError: unsupported operand type(s) for +: 'int
On 3 Oct 2013, at 12:05, Nick Coghlan wrote:
>
> On 3 Oct 2013 06:00, "Victor Stinner" wrote:
> >
> > I don't remember where, but I remember that I also saw things like
> > "str=str, len=len, ...". So you keep the same name, but you use fast
> > local lookups instead of slow builtin lookups.
>
On 3 Oct 2013 06:00, "Victor Stinner" wrote:
>
> I don't remember where, but I remember that I also saw things like
> "str=str, len=len, ...". So you keep the same name, but you use fast
> local lookups instead of slow builtin lookups.
functools uses the local binding trick in lru_cache as a spee
Am 02.10.2013 21:58, schrieb Victor Stinner:
> I don't remember where, but I remember that I also saw things like
> "str=str, len=len, ...". So you keep the same name, but you use fast
> local lookups instead of slow builtin lookups.
In this case they aren't even fast local lookups but (slightly)
31 matches
Mail list logo
