Re: [Python-Dev] backported Enum
On 29 June 2013 06:30, Ethan Furman wrote: >> I would also not be shocked if some people expect failed value >> lookups to raise an IndexError, though I expect they would >> adapt if they get something else that makes sense. >> >> Would it be wrong to create an EnumError that subclasses >> (ValueError, KeyError, AttributeError) and to raise that >> subclass from everything but _StealthProperty and _get_mixins? > > > Wouldn't bother me; I'm not sure what the bar is for adding new exceptions, > though. I'd actually do something a bit more complex, but also cleaner from a type system perspective: class EnumError(Exception): pass class EnumValueError(EnumError, ValueError): pass class EnumAttributeError(EnumError, AttributeError): pass class EnumKeyError(EnumError, KeyError): pass However, it's probably not necessary. The value lookup API should just document clearly which exception it throws. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] add new lambda syntax
http://aruld.info/lambda-expressions-in-java-8-adopts-c-style-syntax/
Lambda expressions in Java 8 adopts C# style syntax.
On Sat, Jun 29, 2013 at 1:39 AM, Thomas Wouters wrote:
>
>
>
> On Fri, Jun 28, 2013 at 7:01 PM, Amaury Forgeot d'Arc
> wrote:
>
>> 2013/6/28 Pynix Wang
>>
>>> I want use coffeescript function syntax to write python lambda
>>> expression so I modified the Grammar file.
>>>
>>> ```
>>> atom: ('(' [yield_expr|testlist_comp|vararglist] ')' |
>>>'[' [testlist_comp] ']' |
>>>'{' [dictorsetmaker] '}' |
>>>NAME | NUMBER | STRING+ | '...' | 'None' | 'True' | 'False')
>>> trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME | '->' text
>>> ```
>>>
>>> but when I write
>>> ```
>>> (x,y=1)->x+y
>>> ```
>>> the parser doesn't go into vararglist.
>>>
>>
>> This grammar is not LL(1) anymore (it's probably LALR now)
>> when seeing "x", it has the choice between testlist_comp and vararglist,
>> and the first one is picked.
>> Python's parser generator only supports LL(1) grammars.
>>
>
> Indeed. You may be able to make this work, but you'd have to fold the bits
> of vararglist you need into testlist_comp, then reject invalid syntax that
> matches the grammar (like "(x=expr for ...)" or "((x+1)=expr)" or
> "(*foo=1)") in the compiler. Something like (untested):
>
> testlist_comp: (test|star_expr) ['=' test]( comp_for | (','
> (test|star_expr) ['=' test])* [','] )
>
> --
> Thomas Wouters
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow
On Thu, Jun 27, 2013 at 12:07 AM, Victor Stinner wrote: > I would to parse an integer in [0; UINT_MAX] to fix the zlib module on > 64-bit system: > http://bugs.python.org/issue18294 > > How should I implement that? Use "O" format and then use > PyLong_Check(), PyLong_AsLong(), and check value <= UINT_MAX? > I ran into the same problem in the _lzma module. My solution was to define a custom converter that does an explicit check before returning the value (see http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l134). On Thu, Jun 27, 2013 at 12:26 AM, Guido van Rossum wrote: > > I would to parse an integer in [0; UINT_MAX] to fix the zlib module on > > 64-bit system: > > http://bugs.python.org/issue18294 > > > > How should I implement that? Use "O" format and then use > > PyLong_Check(), PyLong_AsLong(), and check value <= UINT_MAX? > > Why can't you use the K format? It won't reject out-of-range values, > but it will convert them to in-range so there aren't any attacks > possible based on bypassing the range check. I'm probably > misunderstanding something -- I don't completely understand that bug > report. :-( The point is not to protect against deliberate attacks, but rather to fail loudly (instead of silently) when the caller provides an input that the underlying C library cannot handle. - Nadeem ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow
29.06.13 18:16, Nadeem Vawda написав(ла): I ran into the same problem in the _lzma module. My solution was to define a custom converter that does an explicit check before returning the value (see http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l134). Definitely Argument Clinic should use converters for unsigned integers without wraparound by default. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] winsound.c fix to support python3
Hello,
My name is Tamir Friedman, and I suggest to fix a bug in PlaySound in
winsound library. It's doesn't support the SND_MEMORY feature because its
accepts only "str" and rejects "bytes" type.
therefore i include the fixed source file:
OLD:
static PyObject *
sound_playsound(PyObject *s, PyObject *args)
{
wchar_t *wsound;
int flags;
int ok;
if (PyArg_ParseTuple(args, "Zi:PlaySound", &wsound, &flags)) {
if (flags & SND_ASYNC && flags & SND_MEMORY) {
/* Sidestep reference counting headache; unfortunately this also
prevent SND_LOOP from memory. */
PyErr_SetString(PyExc_RuntimeError, "Cannot play asynchronously
from memory");
return NULL;
}
Py_BEGIN_ALLOW_THREADS
ok = PlaySoundW(wsound, NULL, flags);
Py_END_ALLOW_THREADS
if (!ok) {
PyErr_SetString(PyExc_RuntimeError, "Failed to play sound");
return NULL;
}
Py_INCREF(Py_None);
return Py_None;
}
return NULL;
}
NEW:
static PyObject *
sound_playsound(PyObject *s, PyObject *args)
{
wchar_t *wsound;
int flags;
int ok;
if (PyArg_ParseTuple(args, "z*i:PlaySound", &wsound, &flags)) {
if (flags & SND_ASYNC && flags & SND_MEMORY) {
/* Sidestep reference counting headache; unfortunately this also
prevent SND_LOOP from memory. */
PyErr_SetString(PyExc_RuntimeError, "Cannot play asynchronously
from memory");
return NULL;
}
Py_BEGIN_ALLOW_THREADS
ok = PlaySoundW(wsound, NULL, flags);
Py_END_ALLOW_THREADS
if (!ok) {
PyErr_SetString(PyExc_RuntimeError, "Failed to play sound");
return NULL;
}
Py_INCREF(Py_None);
return Py_None;
}
return NULL;
}
/* Author: Toby Dickenson
*
* Copyright (c) 1999 Toby Dickenson
*
* Permission to use this software in any way is granted without
* fee, provided that the copyright notice above appears in all
* copies. This software is provided "as is" without any warranty.
*/
/* Modified by Guido van Rossum */
/* Beep added by Mark Hammond */
/* Win9X Beep and platform identification added by Uncle Timmy */
/* Example:
import winsound
import time
# Play wav file
winsound.PlaySound('c:/windows/media/Chord.wav', winsound.SND_FILENAME)
# Play sound from control panel settings
winsound.PlaySound('SystemQuestion', winsound.SND_ALIAS)
# Play wav file from memory
data=open('c:/windows/media/Chimes.wav',"rb").read()
winsound.PlaySound(data, winsound.SND_MEMORY)
# Start playing the first bit of wav file asynchronously
winsound.PlaySound('c:/windows/media/Chord.wav',
winsound.SND_FILENAME|winsound.SND_ASYNC)
# But dont let it go for too long...
time.sleep(0.1)
# ...Before stopping it
winsound.PlaySound(None, 0)
*/
#include
#include
#include
PyDoc_STRVAR(sound_playsound_doc,
"PlaySound(sound, flags) - a wrapper around the Windows PlaySound API\n"
"\n"
"The sound argument can be a filename, data, or None.\n"
"For flag values, ored together, see module documentation.");
PyDoc_STRVAR(sound_beep_doc,
"Beep(frequency, duration) - a wrapper around the Windows Beep API\n"
"\n"
"The frequency argument specifies frequency, in hertz, of the sound.\n"
"This parameter must be in the range 37 through 32,767.\n"
"The duration argument specifies the number of milliseconds.\n");
PyDoc_STRVAR(sound_msgbeep_doc,
"MessageBeep(x) - call Windows MessageBeep(x). x defaults to MB_OK.");
PyDoc_STRVAR(sound_module_doc,
"PlaySound(sound, flags) - play a sound\n"
"SND_FILENAME - sound is a wav file name\n"
"SND_ALIAS - sound is a registry sound association name\n"
"SND_LOOP - Play the sound repeatedly; must also specify SND_ASYNC\n"
"SND_MEMORY - sound is a memory image of a wav file\n"
"SND_PURGE - stop all instances of the specified sound\n"
"SND_ASYNC - PlaySound returns immediately\n"
"SND_NODEFAULT - Do not play a default beep if the sound can not be found\n"
"SND_NOSTOP - Do not interrupt any sounds currently playing\n" // Raising RuntimeError if needed
"SND_NOWAIT - Return immediately if the sound driver is busy\n" // Without any errors
"\n"
"Beep(frequency, duration) - Make a beep through the PC speaker.");
static PyObject *
sound_playsound(PyObject *s, PyObject *args)
{
wchar_t *wsound;
int flags;
int ok;
if (PyArg_ParseTuple(args, "Zi:PlaySound", &wsound, &flags)) {
if (flags & SND_ASYNC && flags & SND_MEMORY) {
/* Sidestep reference counting headache; unfortunately this also
prevent SND_LOOP from m
Re: [Python-Dev] [Python-checkins] cpython: Fix memory leak in pyexpat PyUnknownEncodingHandler
I don't know if this is the commit at fault or not, but we are seeing
segfaults in test_xml_etree on the buildbots now.
--David
On Sat, 29 Jun 2013 20:43:22 +0200, christian.heimes
wrote:
> http://hg.python.org/cpython/rev/bd0834b59828
> changeset: 84375:bd0834b59828
> user:Christian Heimes
> date:Sat Jun 29 20:43:13 2013 +0200
> summary:
> Fix memory leak in pyexpat PyUnknownEncodingHandler
> CID 1040367 (#1 of 1): Resource leak (RESOURCE_LEAK)
> leaked_storage: Variable u going out of scope leaks the storage it points to.
>
> files:
> Modules/pyexpat.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
>
> diff --git a/Modules/pyexpat.c b/Modules/pyexpat.c
> --- a/Modules/pyexpat.c
> +++ b/Modules/pyexpat.c
> @@ -1128,8 +1128,10 @@
> }
>
> u = PyUnicode_Decode((char*) template_buffer, 256, name, "replace");
> -if (u == NULL || PyUnicode_READY(u))
> +if (u == NULL || PyUnicode_READY(u)) {
> +Py_DECREF(u);
> return XML_STATUS_ERROR;
> +}
>
> if (PyUnicode_GET_LENGTH(u) != 256) {
> Py_DECREF(u);
>
> --
> Repository URL: http://hg.python.org/cpython
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix memory leak in pyexpat PyUnknownEncodingHandler
Am 29.06.2013 21:29, schrieb R. David Murray: > I don't know if this is the commit at fault or not, but we are seeing > segfaults in test_xml_etree on the buildbots now. Yeah, it's my fault. Thanks! >> u = PyUnicode_Decode((char*) template_buffer, 256, name, "replace"); >> -if (u == NULL || PyUnicode_READY(u))wr >> +Py_DECREF(u); >> return XML_STATUS_ERROR; >> +} Py_DECREF() is wrong as u can be NULL. I have changed the code to use Py_XDECREF(). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] winsound.c fix to support python3
On 6/29/2013 11:59 AM, Tamir Friedman wrote:
Hello,
My name is Tamir Friedman, and I suggest to fix a bug in PlaySound in
winsound library. It's doesn't support the SND_MEMORY feature because
its accepts only "str" and rejects "bytes" type.
therefore i include the fixed source file:
Thank you for tracking down the source of a problem. Please make an
account at bugs.python.org and open a tracker issue. A post here will
get lost. On the issue, either upload a patch file or describe the
change. As near as I can tell, the description for your change might be:
"winsound.c, line NN in sound_playsound function, is currently
if (PyArg_ParseTuple(args, "Zi:PlaySound", &wsound, &flags)) {
I think 'Zi' should be changed for 'z*i' because ..."
--
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue 4199: combining assignment with global & nonlocal
Issue 4199 begins with a self-explanatory comment:
PEP 3104 says that the nonlocal and global statements should
allow a shorthand. ("global x; x = 3" == "global x = 3") This
patch implements that.
Benjamin posted his patch on 2008-10-24. It got postponed to 3.2
because it was too late for 3.1, and then to 3.3 because 3.2 still
fell under the language moratorium, and then was forgotten for 3.3.
Georg Brandl and Jeremy Hylton raised some issues with the patch and
with the PEP's specification:
http://bugs.python.org/issue4199#msg100015
We've gone five years in 3.x without supporting this statement form.
Is it still worth implementing it for 3.4? Or should the issue simply
be closed (and maybe a note added to the PEP that "we didn't do this
after all")?
--amk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow
On 06/29/2013 06:24 PM, Serhiy Storchaka wrote: Definitely Argument Clinic should use converters for unsigned integers without wraparound by default. Argument Clinic 1.0 is a thin layer over PyArg_ParseTuple. But it will support these sorts of converters, and if people have bright ideas about converters to include in-the-box that's totally fine. but-nothing-has-been-formally-accepted-yet-ly yours, //arry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 4199: combining assignment with global & nonlocal
I agree that there are problems with the idea of combining assignment
and global statements, because the ambiguity of "global x, y = p, q"
is just too much to handle. The only case would be if there was only a
single variable, but that fails the test of easy generalization. So
let's close it.
--Guido
On Sat, Jun 29, 2013 at 3:00 PM, A.M. Kuchling wrote:
> Issue 4199 begins with a self-explanatory comment:
>
> PEP 3104 says that the nonlocal and global statements should
> allow a shorthand. ("global x; x = 3" == "global x = 3") This
> patch implements that.
>
> Benjamin posted his patch on 2008-10-24. It got postponed to 3.2
> because it was too late for 3.1, and then to 3.3 because 3.2 still
> fell under the language moratorium, and then was forgotten for 3.3.
>
> Georg Brandl and Jeremy Hylton raised some issues with the patch and
> with the PEP's specification:
> http://bugs.python.org/issue4199#msg100015
>
> We've gone five years in 3.x without supporting this statement form.
> Is it still worth implementing it for 3.4? Or should the issue simply
> be closed (and maybe a note added to the PEP that "we didn't do this
> after all")?
>
> --amk
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 4199: combining assignment with global & nonlocal
Agreed. The currently supported syntax (a global/nonlocal line and an
assignment) is not too painful to figure out the ambiguity of the
proposed syntax.
2013/6/29 Guido van Rossum :
> I agree that there are problems with the idea of combining assignment
> and global statements, because the ambiguity of "global x, y = p, q"
> is just too much to handle. The only case would be if there was only a
> single variable, but that fails the test of easy generalization. So
> let's close it.
>
> --Guido
>
> On Sat, Jun 29, 2013 at 3:00 PM, A.M. Kuchling wrote:
>> Issue 4199 begins with a self-explanatory comment:
>>
>> PEP 3104 says that the nonlocal and global statements should
>> allow a shorthand. ("global x; x = 3" == "global x = 3") This
>> patch implements that.
>>
>> Benjamin posted his patch on 2008-10-24. It got postponed to 3.2
>> because it was too late for 3.1, and then to 3.3 because 3.2 still
>> fell under the language moratorium, and then was forgotten for 3.3.
>>
>> Georg Brandl and Jeremy Hylton raised some issues with the patch and
>> with the PEP's specification:
>> http://bugs.python.org/issue4199#msg100015
>>
>> We've gone five years in 3.x without supporting this statement form.
>> Is it still worth implementing it for 3.4? Or should the issue simply
>> be closed (and maybe a note added to the PEP that "we didn't do this
>> after all")?
>>
>> --amk
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/benjamin%40python.org
--
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
