[Python-Dev] PyObject_IsInstance is dangerous

[Serhiy Storchaka]

PyObject_IsInstance is not safe when used to check if the object is an 
instance of specified builtin type. Typical code:


rc = PyObject_IsInstance(obj, &Someting_Type);
if (rc < 0) return NULL;
if (rc) {
SometingObject *something = (SometingObject *)obj;
something->some_field ...
}

The __class__ attribute can be modified and PyObject_IsInstance() can 
return true if the object has not layout compatible with specified 
structure. And even worse, __class__  can be dynamic property and 
PyObject_IsInstance() can execute arbitrary Python code, that can 
invalidate cached values of pointers and sizes in C code.


More safe way would be to use PyObject_IsSubclass().

rc = PyObject_IsSubclass((Py_Object *)obj->ob_type, &Someting_Type);
if (rc < 0) return NULL;
if (rc) {
SometingObject *something = (SometingObject *)obj;
something->some_field ...
}

For example see issue24102 [1], issue24091 [2] and many other issues 
opened by pkt.


[1] http://bugs.python.org/issue24102
[2] http://bugs.python.org/issue24091

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyObject_IsInstance is dangerous

[Greg Ewing]

Serhiy Storchaka wrote:
PyObject_IsInstance is not safe when used to check if the object is an 
instance of specified builtin type.


The __class__ attribute can be modified and PyObject_IsInstance() can 
return true if the object has not layout compatible with specified 
structure.


Code that requires a particular C layout should be using
PyObject_TypeCheck, not PyObject_IsInstance.

--
Greg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyObject_IsInstance is dangerous

[Serhiy Storchaka]

On 18.05.15 15:14, Greg Ewing wrote:

Serhiy Storchaka wrote:

PyObject_IsInstance is not safe when used to check if the object is an
instance of specified builtin type.

The __class__ attribute can be modified and PyObject_IsInstance() can
return true if the object has not layout compatible with specified
structure.


Code that requires a particular C layout should be using
PyObject_TypeCheck, not PyObject_IsInstance.


Thank you. I didn't know about this helper.

Looks as most (if not all) usages of PyObject_IsInstance are not 
correct. May be modify PyObject_IsInstance so that it will never return 
true if layouts are not compatible?


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyObject_IsInstance is dangerous

[Greg Ewing]

Serhiy Storchaka wrote:
May be modify PyObject_IsInstance so that it will never return 
true if layouts are not compatible?


That wouldn't be a good idea, since PyObject_IsInstance is
meant to reflect the behaviour of python's isinstance()
function, which doesn't care about C layouts.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 484 wishes

[Alex Grönholm]

18.05.2015, 02:50, Guido van Rossum kirjoitti:
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm 
mailto:alex.gronh...@nextday.fi>> wrote:


Looking at PEP 484, I came up with two use cases that I felt were
not catered for:

 1. Specifying that a parameter should be a subclass of another
(example: Type[dict] would match dict or OrderedDict; plain
"Type" would equal "type" from builtins)


I don't understand. What is "Type"? Can you work this out in a full 
example? This code is already okay:


def foo(a: dict):
...

foo(OrderedDict())
This code is passing an /instance/ of OrderedDict. But how can I specify 
that foo() accepts a /subclass/ of dict, and not an instance thereof?


A full example:

def foo(a: Type[dict]):
...

foo(dict)  # ok
foo(OrderedDict)  # ok
foo({'x': 1})  # error


 1. Specifying that a callable should take at least the specified
arguments but would not be limited to them: Callable[[str,
int, ...], Any]

Case #2 works already (Callable[[str, int], Any] if the
unspecified arguments are optional, but not if they're mandatory.
Any thoughts?

For #2 we explicitly debated this and found that there aren't use 
cases known that are strong enough to need additional flexibility in 
the args of a callable. (How is the code calling the callable going to 
know what arguments are safe to pass?) If there really is a need we 
can address in a future revision.
Consider a framework where a request handler always takes a Request 
object as its first argument, but the rest of the arguments could be 
anything. If you want to only allow registration of such callables, you 
could do this:


def calculate_sum(request: Request, *values):
   return sum(values)

def register_request_handler(handler: Callable[[Request, ...], Any]):
   ...

--
--Guido van Rossum (python.org/~guido )


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 484 wishes

[Ivan Levkivskyi]

> >  Looking at PEP 484, I came up with two use cases that I felt were not
> > catered for:
> >
> >1. Specifying that a parameter should be a subclass of another
> >(example: Type[dict] would match dict or OrderedDict; plain "Type"
would
> >equal "type" from builtins)
> >
> >
> I don't understand. What is "Type"? Can you work this out in a full
> example? This code is already okay:
>
> def foo(a: dict):
> ...
>
> foo(OrderedDict())

I think Alex means this: https://github.com/ambv/typehinting/issues/107
This could be really useful, for example:

def fancy_instantiate(cls: Type[T]) -> T:
...
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 484 wishes

[Guido van Rossum]

On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm 
wrote:

>
>
> 18.05.2015, 02:50, Guido van Rossum kirjoitti:
>
>  On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm 
> wrote:
>
>>  Looking at PEP 484, I came up with two use cases that I felt were not
>> catered for:
>>
>>1. Specifying that a parameter should be a subclass of another
>>(example: Type[dict] would match dict or OrderedDict; plain "Type" would
>>equal "type" from builtins)
>>
>>
>  I don't understand. What is "Type"? Can you work this out in a full
> example? This code is already okay:
>
>  def foo(a: dict):
> ...
>
>  foo(OrderedDict())
>
> This code is passing an *instance* of OrderedDict. But how can I specify
> that foo() accepts a *subclass* of dict, and not an instance thereof?
>
> A full example:
>
> def foo(a: Type[dict]):
> ...
>
> foo(dict)  # ok
> foo(OrderedDict)  # ok
> foo({'x': 1})  # error
>

You want the argument to be a *class*. We currently don't support that
beyond using 'type' as the annotation. We may get to this in a future
version; it is relatively uncommon. As to what notation to use, perhaps it
would make more sense to use Class and Class[dict], since in the world of
PEP 484, a class is a concrete thing that you can instantiate, while a type
is an abstraction used to describe the possible values of a
variable/argument/etc.

Also, what you gave is still not a full example, since you don't show what
you are going to do with that type. Not every class can be easily
instantiated (without knowing the specific signature). So if you were
planning to instantiate it, perhaps you should use Callable[..., dict] as
the type instead. (The ellipsis is not yet supported by mypy --
https://github.com/JukkaL/mypy/issues/393 -- but it is allowed by the PEP.)


>
>
>>
>>1. Specifying that a callable should take at least the specified
>>arguments but would not be limited to them: Callable[[str, int, ...], Any]
>>
>> Case #2 works already (Callable[[str, int], Any] if the unspecified
>> arguments are optional, but not if they're mandatory. Any thoughts?
>>
> For #2 we explicitly debated this and found that there aren't use cases
> known that are strong enough to need additional flexibility in the args of
> a callable. (How is the code calling the callable going to know what
> arguments are safe to pass?) If there really is a need we can address in a
> future revision.
>
> Consider a framework where a request handler always takes a Request object
> as its first argument, but the rest of the arguments could be anything. If
> you want to only allow registration of such callables, you could do this:
>
> def calculate_sum(request: Request, *values):
>return sum(values)
>
> def register_request_handler(handler: Callable[[Request, ...], Any]):
>...
>

Hm... Yeah, you'd be stuck with using Callable[..., Any] for now. Maybe in
a future version of the PEP. (We can't boil the ocean of typing in one PEP.
:-)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 485 isclose() implementation review requested

[Chris Barker]

Thanks Cristian, that clears up a couple things -- got it compiling without
warning.

But I also discovered that I must have not pushed the latest copy yesterday.

It's on a machine at home -- I'll push it tonight. But the copy on gitHub
now is mostly good -- I think the only changes are handling the docsstrings
better and some more/better tests.

-Chris





On Sun, May 17, 2015 at 4:16 PM, Christian Heimes 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2015-05-18 01:02, Chris Barker wrote:
> > * Is there a better way to create a False or True than::
> >
> > PyBool_FromLong(0) and PyBool_FromLong(1)
>
> You can use the macros Py_RETURN_TRUE and Py_RETURN_FALSE instead of
> return PyBool_FromLong(0).
>
>
> > * Style question: should I put brackets in an if clause that has
> > only one line?::
> >
> > if (some_check) { just_this_one_expression }
>
> I prefer the extra brackets because they make the code more explicit.
> It's really a matter of taste.
>
> > * I can't find docs for PyDoc_STRVAR: but it looks like it should
> > use it -- how?
>
> PyDoc_STRVAR(functionname_doc,
> "isclose(foo) -> bool\n\
> \n\
> long doc string.");
>
> > * I'm getting a warning in my PyMethodDef clause::
> >
> > static PyMethodDef IsCloseMethods[] = { {"isclose", isclose_c,
> > METH_VARARGS | METH_KEYWORDS, "determine if two floating point
> > numbers are close"}, {NULL, NULL, 0, NULL}/* Sentinel */
> > };
>
> You have to type cast the function pointer to a PyCFunction here:
>
>   (PyCFunction)isclose_c
>
> The type cast is required for KEYWORD functions and NOARGS functions.
>
> Christian
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 485 isclose() implementation review requested

[Christian Heimes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-05-18 17:49, Chris Barker wrote:
> Thanks Cristian, that clears up a couple things -- got it
> compiling without warning.
> 
> But I also discovered that I must have not pushed the latest copy
> yesterday.
> 
> It's on a machine at home -- I'll push it tonight. But the copy on 
> gitHub now is mostly good -- I think the only changes are handling
> the docsstrings better and some more/better tests.

You're welcome!

Does your latest patch handle NaN, too? I only noticed infinity checks
but no explicit check for NaN.

Christian

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVWgyrAAoJEIZoUkkhLbaJhBsH/3gH7Z1+otWwR6hIYjNU4OjK
xjPmGeypisU6UDxfQa+lIHg1rEmyxlSbkXtn2DYysw9CMentK/XclF8GzWAA/ySV
m0UE4+hzcWB7fsOLgbCxQKfNTEM/jp7D2z3qIZTknEecHENx552AaEfTXRTWQKHK
QLh0sLA3QrOzUkOf+EXJQHlYvxf+F71PVyfOX8/m3XHhaQrpb70AGktsUPRDN3yc
blY6SSQoV1uhw+/crqz34BoPGipAkZdq9abyz4Ja0adC8hT++7rbVldFdsrDIPdQ
MX30atV+ZQ2Mb5NqJkmEjCKF5uXvwvlP8ijgz5nZKZ9db+9Z8YS0/e7UrPb85uM=
=7N7z
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 484 wishes

[Alex Grönholm]

18.05.2015, 18:05, Guido van Rossum kirjoitti:
On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm 
mailto:alex.gronh...@nextday.fi>> wrote:




18.05.2015, 02:50, Guido van Rossum kirjoitti:

On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
mailto:alex.gronh...@nextday.fi>> wrote:

Looking at PEP 484, I came up with two use cases that I felt
were not catered for:

 1. Specifying that a parameter should be a subclass of
another (example: Type[dict] would match dict or
OrderedDict; plain "Type" would equal "type" from builtins)


I don't understand. What is "Type"? Can you work this out in a
full example? This code is already okay:

def foo(a: dict):
...

foo(OrderedDict())

This code is passing an /instance/ of OrderedDict. But how can I
specify that foo() accepts a /subclass/ of dict, and not an
instance thereof?

A full example:

def foo(a: Type[dict]):
...

foo(dict)  # ok
foo(OrderedDict)  # ok
foo({'x': 1})  # error


You want the argument to be a *class*. We currently don't support that 
beyond using 'type' as the annotation. We may get to this in a future 
version; it is relatively uncommon. As to what notation to use, 
perhaps it would make more sense to use Class and Class[dict], since 
in the world of PEP 484, a class is a concrete thing that you can 
instantiate, while a type is an abstraction used to describe the 
possible values of a variable/argument/etc.


Also, what you gave is still not a full example, since you don't show 
what you are going to do with that type. Not every class can be easily 
instantiated (without knowing the specific signature). So if you were 
planning to instantiate it, perhaps you should use Callable[..., dict] 
as the type instead. (The ellipsis is not yet supported by mypy -- 
https://github.com/JukkaL/mypy/issues/393 -- but it is allowed by the 
PEP.)

Here's one example, straight from the code of my new framework:

@typechecked
def register_extension_type(ext_type: str, extension_class: type, 
replace: bool=False):

"""
Adds a new extension type that can be used with a dictionary based 
configuration.


:param ext_type: the extension type identifier
:param extension_class: a class that implements IExtension
:param replace: ``True`` to replace an existing type
"""

assert_subclass('extension_class', extension_class, IExtension)
if ext_type in extension_types and not replace:
raise ValueError('Extension type "{}" already 
exists'.format(ext_type))


extension_types[ext_type] = extension_class

I would like to declare the second argument as "extension_class: 
Type[IExtension]" (or Class[IExtension], doesn't matter to me). 
Likewise, the type hint for "extension_types" should be "Dict[str, 
Type[IExtension]]".



 1. Specifying that a callable should take at least the
specified arguments but would not be limited to them:
Callable[[str, int, ...], Any]

Case #2 works already (Callable[[str, int], Any] if the
unspecified arguments are optional, but not if they're
mandatory. Any thoughts?

For #2 we explicitly debated this and found that there aren't use
cases known that are strong enough to need additional flexibility
in the args of a callable. (How is the code calling the callable
going to know what arguments are safe to pass?) If there really
is a need we can address in a future revision.

Consider a framework where a request handler always takes a
Request object as its first argument, but the rest of the
arguments could be anything. If you want to only allow
registration of such callables, you could do this:

def calculate_sum(request: Request, *values):
   return sum(values)

def register_request_handler(handler: Callable[[Request, ...], Any]):
   ...


Hm... Yeah, you'd be stuck with using Callable[..., Any] for now. 
Maybe in a future version of the PEP. (We can't boil the ocean of 
typing in one PEP. :-)


--
--Guido van Rossum (python.org/~guido )


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 484 wishes

[Guido van Rossum]

Can you add your example to the issue?
https://github.com/ambv/typehinting/issues/107

We're trying to finish up PEP 484 in the next few days (wait for an
announcement :-) and we just don't have time for every use case; but over
the course of 3.5 we will be adding features that are considered useful,
and we'll keep the issue open to remind us of it. Until then you'll have to
use plain "type" as the annotation (still better than "Any". :-)

On Mon, May 18, 2015 at 11:01 AM, Alex Grönholm 
wrote:

>
>
> 18.05.2015, 18:05, Guido van Rossum kirjoitti:
>
>  On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm  > wrote:
>
>>
>>
>> 18.05.2015, 02:50, Guido van Rossum kirjoitti:
>>
>>  On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm > > wrote:
>>
>>>  Looking at PEP 484, I came up with two use cases that I felt were not
>>> catered for:
>>>
>>>1. Specifying that a parameter should be a subclass of another
>>>(example: Type[dict] would match dict or OrderedDict; plain "Type" would
>>>equal "type" from builtins)
>>>
>>>
>>  I don't understand. What is "Type"? Can you work this out in a full
>> example? This code is already okay:
>>
>>  def foo(a: dict):
>> ...
>>
>>  foo(OrderedDict())
>>
>>  This code is passing an *instance* of OrderedDict. But how can I
>> specify that foo() accepts a *subclass* of dict, and not an instance
>> thereof?
>>
>> A full example:
>>
>> def foo(a: Type[dict]):
>> ...
>>
>>   foo(dict)  # ok
>> foo(OrderedDict)  # ok
>> foo({'x': 1})  # error
>>
>
>  You want the argument to be a *class*. We currently don't support that
> beyond using 'type' as the annotation. We may get to this in a future
> version; it is relatively uncommon. As to what notation to use, perhaps it
> would make more sense to use Class and Class[dict], since in the world of
> PEP 484, a class is a concrete thing that you can instantiate, while a type
> is an abstraction used to describe the possible values of a
> variable/argument/etc.
>
> Also, what you gave is still not a full example, since you don't show what
> you are going to do with that type. Not every class can be easily
> instantiated (without knowing the specific signature). So if you were
> planning to instantiate it, perhaps you should use Callable[..., dict] as
> the type instead. (The ellipsis is not yet supported by mypy --
> https://github.com/JukkaL/mypy/issues/393 -- but it is allowed by the
> PEP.)
>
> Here's one example, straight from the code of my new framework:
>
>  @typechecked
> def register_extension_type(ext_type: str, extension_class: type, replace:
> bool=False):
>  """
> Adds a new extension type that can be used with a dictionary based
> configuration.
>
> :param ext_type: the extension type identifier
> :param extension_class: a class that implements IExtension
> :param replace: ``True`` to replace an existing type
> """
>
> assert_subclass('extension_class', extension_class, IExtension)
> if ext_type in extension_types and not replace:
> raise ValueError('Extension type "{}" already
> exists'.format(ext_type))
>
> extension_types[ext_type] = extension_class
>
> I would like to declare the second argument as "extension_class:
> Type[IExtension]" (or Class[IExtension], doesn't matter to me). Likewise,
> the type hint for "extension_types" should be "Dict[str, Type[IExtension]]".
>
>
>
>>
>>
>>>
>>>1. Specifying that a callable should take at least the specified
>>>arguments but would not be limited to them: Callable[[str, int, ...], 
>>> Any]
>>>
>>> Case #2 works already (Callable[[str, int], Any] if the unspecified
>>> arguments are optional, but not if they're mandatory. Any thoughts?
>>>
>> For #2 we explicitly debated this and found that there aren't use cases
>> known that are strong enough to need additional flexibility in the args of
>> a callable. (How is the code calling the callable going to know what
>> arguments are safe to pass?) If there really is a need we can address in a
>> future revision.
>>
>>  Consider a framework where a request handler always takes a Request
>> object as its first argument, but the rest of the arguments could be
>> anything. If you want to only allow registration of such callables, you
>> could do this:
>>
>> def calculate_sum(request: Request, *values):
>>return sum(values)
>>
>> def register_request_handler(handler: Callable[[Request, ...], Any]):
>>...
>>
>
>  Hm... Yeah, you'd be stuck with using Callable[..., Any] for now. Maybe
> in a future version of the PEP. (We can't boil the ocean of typing in one
> PEP. :-)
>
> --
> --Guido van Rossum (python.org/~guido )
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
__

[Python-Dev] Gcode path

[Lisa Colvard]

I am trying to get Replicatorg to use python to gcode but it keeps giving the 
error "generate Gcode  requires that a Python interpreter be installed.  Would 
you like to visit the Python download page now?

I tell it no because I have it installed.  I have even gone in and selected the 
path for the gcode.  It still gives me the same error.  How can I fix this?

Thanks,

Lisa Colvard, Ed.D.
Conway High School
Media/Technology Specialist
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Gcode path

[Guido van Rossum]

Hi Lisa,

It's unlikely that anyone on this list can help you with this. It's a
question you should ask of the ReplicatorG people, not the Python people...

--Guido

On Mon, May 18, 2015 at 12:02 PM, Lisa Colvard <
lcolv...@horrycountyschools.net> wrote:

>  I am trying to get Replicatorg to use python to gcode but it keeps
> giving the error “generate Gcode  requires that a Python interpreter be
> installed.  Would you like to visit the Python download page now?
>
>
>
> I tell it no because I have it installed.  I have even gone in and
> selected the path for the gcode.  It still gives me the same error.  How
> can I fix this?
>
>
>
> Thanks,
>
>
>
> Lisa Colvard, Ed.D.
>
> Conway High School
>
> Media/Technology Specialist
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Gcode path

[Terry Reedy]

On 5/18/2015 4:18 PM, Guido van Rossum wrote:


It's unlikely that anyone on this list can help you with this. It's a
question you should ask of the ReplicatorG people, not the Python people...


If that does not work, try stackoverflow, or possibly even python-list. 
 This list is focused only on development of future python releases.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Gcode path

[Chris Barker]

Lisa,

As noted, not the right list.

But seeing this kind of stuff done in High Schools is GREAT!

So one suggestion:

If this is Windows, there are two versions of python for Windows: 32bit and
64bit -- if an installer for a third-party package is looking for one of
those, and the other is installed, you will get the confusing error
something like "python is not installed", when it really means "the correct
version of python is not installed".

So make sure you see which version Replicatorg is expecting and make sure
that's the one you installed.

Good luck,

-Chris



On Mon, May 18, 2015 at 1:18 PM, Guido van Rossum  wrote:

> Hi Lisa,
>
> It's unlikely that anyone on this list can help you with this. It's a
> question you should ask of the ReplicatorG people, not the Python people...
>
> --Guido
>
> On Mon, May 18, 2015 at 12:02 PM, Lisa Colvard <
> lcolv...@horrycountyschools.net> wrote:
>
>>  I am trying to get Replicatorg to use python to gcode but it keeps
>> giving the error “generate Gcode  requires that a Python interpreter be
>> installed.  Would you like to visit the Python download page now?
>>
>>
>>
>> I tell it no because I have it installed.  I have even gone in and
>> selected the path for the gcode.  It still gives me the same error.  How
>> can I fix this?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Lisa Colvard, Ed.D.
>>
>> Conway High School
>>
>> Media/Technology Specialist
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com