Re: [Python-Dev] Python C API: Problem sending tuple to a method of a python Class

2012-01-10 Thread Stefan Behnel 
Hi,

sorry for hooking into this off-topic thread.

Amaury Forgeot d'Arc, 09.01.2012 19:09:
> 2012/1/9 
>> I am trying to send a tuple to a method of a python class and I got a Run
>> failed from netbeans compiler
>> when I want to send a tuple to a simple method in a module it works,when I
>> want to send a simple parameter to a method of a clas it works also but not
>> a tuple to a method of a class
> 
> This mailing list is for the development *of* python.
> For development *with* python, please ask your questions on
> the comp.lang.python group or the [email protected] mailing list.
> There you will find friendly people willing to help.

It's also worth mentioning the cython-users mailing list here, in case the
OP cares about simplifying these kinds of issues from the complexity of
C/C++ into Python. Cython is a really good and simple way to implement
these kinds of language interactions, also for embedding Python.


> [for your particular question: keep in mind that PyObject_Call takes
> arguments as a tuple;
> if you want to pass one tuple, you need to build a 1-tuple around your
> tuple]

The presented code also requires a whole lot of fixes (specifically in the
error handling parts) that Cython would basically just handle for you already.

Stefan

___
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] Python C API: Problem sending tuple to a method of a python Class

2012-01-10 Thread Matt Joiner 
Perhaps the python-dev mailing list should be renamed to python-core.

On Tue, Jan 10, 2012 at 7:35 PM, Stefan Behnel  wrote:
> Hi,
>
> sorry for hooking into this off-topic thread.
>
> Amaury Forgeot d'Arc, 09.01.2012 19:09:
>> 2012/1/9 
>>> I am trying to send a tuple to a method of a python class and I got a Run
>>> failed from netbeans compiler
>>> when I want to send a tuple to a simple method in a module it works,when I
>>> want to send a simple parameter to a method of a clas it works also but not
>>> a tuple to a method of a class
>>
>> This mailing list is for the development *of* python.
>> For development *with* python, please ask your questions on
>> the comp.lang.python group or the [email protected] mailing list.
>> There you will find friendly people willing to help.
>
> It's also worth mentioning the cython-users mailing list here, in case the
> OP cares about simplifying these kinds of issues from the complexity of
> C/C++ into Python. Cython is a really good and simple way to implement
> these kinds of language interactions, also for embedding Python.
>
>
>> [for your particular question: keep in mind that PyObject_Call takes
>> arguments as a tuple;
>> if you want to pass one tuple, you need to build a 1-tuple around your
>> tuple]
>
> The presented code also requires a whole lot of fixes (specifically in the
> error handling parts) that Cython would basically just handle for you already.
>
> Stefan
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com



-- 
ಠ_ಠ
___
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] [Python-checkins] cpython: Issue #12760: Add a create mode to open(). Patch by David Townshend.

2012-01-10 Thread Nick Coghlan 
On Tue, Jan 10, 2012 at 7:40 AM, charles-francois.natali
 wrote:
> http://hg.python.org/cpython/rev/bf609baff4d3
> changeset:   74315:bf609baff4d3
> user:        Charles-François Natali 
> date:        Mon Jan 09 22:40:02 2012 +0100
> summary:
>  Issue #12760: Add a create mode to open(). Patch by David Townshend.

To help make the 'x' more intuitive, it would be helpful if the mode
was referred to as "exclusive create" in the docs (at least once,
anyway), and the What's New entry stated explicitly that 'x' is used
based on the C11 precedent. Otherwise, I'm sure I'll be far from the
only one thinking "why not 'c'?". People shouldn't have to go read the
tracker item to find out the reason 'x' is used instead of 'c'.

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] devguide: Backporting is obsolete. Add details that I had to learn.

2012-01-10 Thread Rob Cliffe 
But "minor version" and "major version" are readily understandable to 
the general reader, e.g. me, whereas "feature release" and "release 
series" I find are not.  Couldn't the first two terms be defined once 
and then used throughout?

Rob Cliffe

On 10/01/2012 04:05, Terry Reedy wrote:

On 1/9/2012 8:52 PM, Nick Coghlan wrote:
On Tue, Jan 10, 2012 at 7:59 AM, Antoine Pitrou  
wrote:

Please avoid using the terms "minor version" and "major version", they
are confusing.


Indeed. "Feature release" (2.7, 3.2, 3.3) and "release series" (2.x,
3.x) are the least confusing terms we have available.


I minimally edited what was already there to correct what is now an 
error. The change comes immediately after a section defining major, 
minor, and micro releases. To change terms,

http://docs.python.org/devguide/devcycle.html
and possibly other pages needs more extensive editing.


___
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] devguide: Backporting is obsolete. Add details that I had to learn.

2012-01-10 Thread Anthony Kong 
I don't find 'major' and 'minor' confusing too. Maybe because it is the
designation used in linux community for years.



On Tue, Jan 10, 2012 at 7:49 PM, Rob Cliffe wrote:

> But "minor version" and "major version" are readily understandable to the
> general reader, e.g. me, whereas "feature release" and "release series" I
> find are not.  Couldn't the first two terms be defined once and then used
> throughout?
> Rob Cliffe
>
>
> On 10/01/2012 04:05, Terry Reedy wrote:
>
>> On 1/9/2012 8:52 PM, Nick Coghlan wrote:
>>
>>> On Tue, Jan 10, 2012 at 7:59 AM, Antoine Pitrou
>>>  wrote:
>>>
 Please avoid using the terms "minor version" and "major version", they
 are confusing.

>>>
>>> Indeed. "Feature release" (2.7, 3.2, 3.3) and "release series" (2.x,
>>> 3.x) are the least confusing terms we have available.
>>>
>>
>> I minimally edited what was already there to correct what is now an
>> error. The change comes immediately after a section defining major, minor,
>> and micro releases. To change terms,
>> http://docs.python.org/**devguide/devcycle.html
>> and possibly other pages needs more extensive editing.
>>
>>  __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> anthony.hw.kong%40gmail.com
>
___
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] devguide: Backporting is obsolete. Add details that I had to learn.

2012-01-10 Thread Barry Warsaw 
On Jan 10, 2012, at 09:03 PM, Anthony Kong wrote:

>I don't find 'major' and 'minor' confusing too. Maybe because it is the
>designation used in linux community for years.

Neither do I.  I read them as aliases for "leftmost digit" and "middle digit"
respectively, regardless of Python's interpretation of them.

-Barry
___
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] AUTO: Jon K Peck is out of the office (returning 01/12/2012)

2012-01-10 Thread Jon K Peck 

I am out of the office until 01/12/2012.

I will be out of the office Monda through Wednesday with limited access to
email.


Note: This is an automated response to your message  "Python-Dev Digest,
Vol 102, Issue 26" sent on 1/9/2012 21:05:32.

This is the only notification you will receive while this person is away.

___
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] Python C API: Problem sending tuple to a method of a python Class

2012-01-10 Thread Stefan Behnel 
Matt Joiner, 10.01.2012 09:40:
> Perhaps the python-dev mailing list should be renamed to python-core.

Well, there *is* a rather visible warning on the list subscription page
that tells people that it's most likely not the list they actually want to
use. If they manage to ignore that, I doubt that a different list name
would fix it for them.

Stefan

___
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] devguide: Backporting is obsolete. Add details that I had to learn.

2012-01-10 Thread Antoine Pitrou 
On Tue, 10 Jan 2012 08:49:04 +
Rob Cliffe  wrote:
> But "minor version" and "major version" are readily understandable to 
> the general reader, e.g. me, whereas "feature release" and "release 
> series" I find are not.  Couldn't the first two terms be defined once 
> and then used throughout?

To me "minor" is a bugfix release, e.g. 2.7.2, and "major" is a feature
release, e.g. 3.3.  I have a hard time considering 3.2 or 3.3 "minor".

Regards

Antoine.


___
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] [Python-checkins] cpython (2.7): Fix stock symbol for Microsoft

2012-01-10 Thread Victor Stinner 
You may port the fix to 3.2 and 3.3.

Victor

2012/1/10 raymond.hettinger :
> http://hg.python.org/cpython/rev/068ce5d7f7e7
> changeset:   74320:068ce5d7f7e7
> branch:      2.7
> user:        Raymond Hettinger 
> date:        Tue Jan 10 09:51:51 2012 +
> summary:
>  Fix stock symbol for Microsoft
>
> files:
>  Doc/library/sqlite3.rst |  4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/Doc/library/sqlite3.rst b/Doc/library/sqlite3.rst
> --- a/Doc/library/sqlite3.rst
> +++ b/Doc/library/sqlite3.rst
> @@ -66,7 +66,7 @@
>
>    # Larger example
>    for t in [('2006-03-28', 'BUY', 'IBM', 1000, 45.00),
> -             ('2006-04-05', 'BUY', 'MSOFT', 1000, 72.00),
> +             ('2006-04-05', 'BUY', 'MSFT', 1000, 72.00),
>              ('2006-04-06', 'SELL', 'IBM', 500, 53.00),
>             ]:
>        c.execute('insert into stocks values (?,?,?,?,?)', t)
> @@ -86,7 +86,7 @@
>    (u'2006-01-05', u'BUY', u'RHAT', 100, 35.14)
>    (u'2006-03-28', u'BUY', u'IBM', 1000, 45.0)
>    (u'2006-04-06', u'SELL', u'IBM', 500, 53.0)
> -   (u'2006-04-05', u'BUY', u'MSOFT', 1000, 72.0)
> +   (u'2006-04-05', u'BUY', u'MSFT', 1000, 72.0)
>    >>>
>
>
>
> --
> 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] Sphinx version for Python 2.x docs

2012-01-10 Thread Sandro Tosi 
Hi all,

On Sat, Aug 27, 2011 at 07:47, Georg Brandl  wrote:
> One of the main reasons for keeping Sphinx compatibility to 0.6.x was to
> enable distributions (like Debian) to build the docs for the Python they ship
> with the version of Sphinx that they ship.
>
> This should now be fine with 1.0.x, so since you are ready to do the work of
> converting the 2.7 Doc sources, it will be accepted.  The argument of easier
> backports is a very good one.

Not exactly as quickly as I would, I started to work on upgrading
sphinx for 2.7. Currently I've all the preliminary patches at:

http://hg.python.org/sandbox/morph/shortlog/5057ce392838

in the 2.7-sphinx branch (they fix one thing at a time, they'll be
collapsed once all ready).

During the build process, there are some warnings that I can understand:

writing output... [100%] whatsnew/index
/home/morph/cpython/morph_sandbox/Doc/glossary.rst:520: WARNING:
unknown keyword: nonlocal
/home/morph/cpython/morph_sandbox/Doc/library/stdtypes.rst:2372:
WARNING: more than one target found for cross-reference u'next':
iterator.next, multifile.MultiFile.next, csv.csvreader.next,
dbhash.dbhash.next, mailbox.oldmailbox.next, ttk.Treeview.next,
nntplib.NNTP.next, file.next, bsddb.bsddbobject.next,
tarfile.TarFile.next, generator.next
/home/morph/cpython/morph_sandbox/Doc/library/stdtypes.rst:2372:
WARNING: more than one target found for cross-reference u'next':
iterator.next, multifile.MultiFile.next, csv.csvreader.next,
dbhash.dbhash.next, mailbox.oldmailbox.next, ttk.Treeview.next,
nntplib.NNTP.next, file.next, bsddb.bsddbobject.next,
tarfile.TarFile.next, generator.next
/home/morph/cpython/morph_sandbox/Doc/library/sys.rst:651: WARNING:
unknown keyword: None
/home/morph/cpython/morph_sandbox/Doc/library/sys.rst:712: WARNING:
unknown keyword: None
/home/morph/cpython/morph_sandbox/Doc/reference/datamodel.rst:1942:
WARNING: unknown keyword: not in
/home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1101:
WARNING: unknown keyword: not in
/home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1135:
WARNING: unknown keyword: not in
/home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1176:
WARNING: unknown keyword: not in
/home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1184:
WARNING: unknown keyword: is not
/home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1362:
WARNING: unknown keyword: is not
/home/morph/cpython/morph_sandbox/Doc/reference/simple_stmts.rst:700:
WARNING: unknown keyword: None
/home/morph/cpython/morph_sandbox/Doc/reference/simple_stmts.rst:729:
WARNING: unknown keyword: None
/home/morph/cpython/morph_sandbox/Doc/reference/simple_stmts.rst:729:
WARNING: unknown keyword: None
writing additional files... genindex py-modindex search download index
opensearch

Do you know how I can fix them?

Thanks & Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
___
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] devguide: Backporting is obsolete. Add details that I had to learn.

2012-01-10 Thread Glyph 

On Jan 10, 2012, at 7:57 AM, Antoine Pitrou wrote:

> On Tue, 10 Jan 2012 08:49:04 +
> Rob Cliffe  wrote:
>> But "minor version" and "major version" are readily understandable to 
>> the general reader, e.g. me, whereas "feature release" and "release 
>> series" I find are not.  Couldn't the first two terms be defined once 
>> and then used throughout?
> 
> To me "minor" is a bugfix release, e.g. 2.7.2, and "major" is a feature
> release, e.g. 3.3.  I have a hard time considering 3.2 or 3.3 "minor".

Whatever your personal feelings, there is a precedent established in the API:

>>> sys.version_info.major
2
>>> sys.version_info.minor
7
>>> sys.version_info.micro
1

This strikes me as the most authoritative definition of the terms, in the 
context of Python.  (Although the fact that this precedent is widely 
established elsewhere doesn't hurt.)

Whatever term is chosen, the important thing is to apply the terminology 
consistently so that it's clear what is meant.  I doubt that anyone has a term 
which every reader will intuitively and immediately associate with "middle 
dot-separated digit increment by one".

If you want to emphasize the importance of a release, just choose a subjective 
term aside from "major" or "minor".

-glyph

___
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] devguide: Backporting is obsolete. Add details that I had to learn.

2012-01-10 Thread Matt Joiner 
http://semver.org/

This has made sense since Gentoo days.

On Tue, Jan 10, 2012 at 11:57 PM, Antoine Pitrou  wrote:
> On Tue, 10 Jan 2012 08:49:04 +
> Rob Cliffe  wrote:
>> But "minor version" and "major version" are readily understandable to
>> the general reader, e.g. me, whereas "feature release" and "release
>> series" I find are not.  Couldn't the first two terms be defined once
>> and then used throughout?
>
> To me "minor" is a bugfix release, e.g. 2.7.2, and "major" is a feature
> release, e.g. 3.3.  I have a hard time considering 3.2 or 3.3 "minor".
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com
___
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] Python C API: Problem sending tuple to a method of a python Class

2012-01-10 Thread Matt Joiner 
I suspect it actually would fix the confusion. "dev" usually means
development, not "core implementation development". People float past
looking for dev help... python-dev. Python-list is a bit generic.

On Tue, Jan 10, 2012 at 11:17 PM, Stefan Behnel  wrote:
> Matt Joiner, 10.01.2012 09:40:
>> Perhaps the python-dev mailing list should be renamed to python-core.
>
> Well, there *is* a rather visible warning on the list subscription page
> that tells people that it's most likely not the list they actually want to
> use. If they manage to ignore that, I doubt that a different list name
> would fix it for them.
>
> Stefan
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com
___
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] devguide: Backporting is obsolete. Add details that I had to learn.

2012-01-10 Thread Antoine Pitrou 
On Tue, 10 Jan 2012 11:57:03 -0500
Glyph  wrote:
> 
> Whatever your personal feelings, there is a precedent established in the API:
> 
> >>> sys.version_info.major
> 2
> >>> sys.version_info.minor
> 7
> >>> sys.version_info.micro
> 1
> 
> This strikes me as the most authoritative definition of the terms, in the 
> context of Python.  (Although the fact that this precedent is widely 
> established elsewhere doesn't hurt.)

While authoritative, it is still counter-intuitive and misleading for
some people (including Nick and me, apparently). I never use the field
names myself, I use version_info as a 3-tuple.

> Whatever term is chosen, the important thing is to apply the terminology 
> consistently so that it's clear what is meant.  I doubt that anyone has a 
> term which every reader will intuitively and immediately associate with 
> "middle dot-separated digit increment by one".

I changed the terminology in my latest changeset:
http://hg.python.org/devguide/rev/f39d063ab3dd

Important to notice is that the major / minor distinction isn't
relevant in most contexts, while the feature / bugfix distinction is.
Where "major" plays a role, we can simply avoid the term by talking
about Python 2 and Python 3, which is more explicit too. I doubt this
needs to be revisited before 10 years anyway.

Regards

Antoine.
___
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] svn.python.org certificate expired

2012-01-10 Thread Martin v. Löwis 
> It seems that svn.python.org certificate expired today (09/01/2012).

I have now replaced the certificate. The current one will expire on
Chistmas 2013.

Regards,
Martin
___
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] devguide: Backporting is obsolete. Add details that I had to learn.

2012-01-10 Thread Terry Reedy 

On 1/10/2012 12:14 PM, Antoine Pitrou wrote:


I changed the terminology in my latest changeset:
http://hg.python.org/devguide/rev/f39d063ab3dd

Important to notice is that the major / minor distinction isn't
relevant in most contexts, while the feature / bugfix distinction is.
Where "major" plays a role, we can simply avoid the term by talking
about Python 2 and Python 3, which is more explicit too. I doubt this
needs to be revisited before 10 years anyway.


FWIW, I like the changes, and you did them better than I would have.

--
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

Re: [Python-Dev] Python as a Metro-style App

2012-01-10 Thread Martin v. Löwis 
Am 09.01.2012 07:13, schrieb Jeff Hardy:
> On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou  wrote:
>> Depending on the extent of removed/disabled functionality, it might not
>> be very interesting to have a Metro port at all.
> 
> Win 8 is practically a new OS target - the nt module may need to be
> replaced with a metro module to handle it well.

No, it's not. Everything continues to work just fine on Windows 8,
as long as we keep developing desktop apps.

Only if Metro Apps are the target things may need to be replaced (but
only very few changes are necessary to the nt module to make it compile).

Regards,
Martin
___
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] Python as a Metro-style App

2012-01-10 Thread Martin v. Löwis 
> I haven't been following this thread so maybe this was already
> discussed, but on the whole "new OS target" thing - if people want to
> write immersive apps in Python then there will need to be a new build
> of Python.  One thing that might make that easier is the fact that
> the C runtime is still available to metro apps, even if the C runtime
> calls a banned API.

Does that hold for all versions of the C runtime (i.e. is msvcr80.dll
also exempt from the ban, or just the version that comes with VS 11)?

> So to the extent that Python is just a C program
> the "port" should be pretty easy and mostly involve disabling
> functionality that isn't available at all to metro apps.

See the start of the thread: I tried to create a "WinRT Component DLL",
and that failed, as VS would refuse to compile any C file in such a
project. Not sure whether this is triggered by defining WINAPI_FAMILY=2,
or any other compiler setting.

I'd really love to use WINAPI_FAMILY=2, as compiler errors are much
easier to fix than verifier errors.

Regards,
Martin
___
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] Python C API: Problem sending tuple to a method of a python Class

2012-01-10 Thread Oleg Broytman 
Hello.

   We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/news
group is the best place; there are Python developers who participate in it;
you may get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.

On Mon, Jan 09, 2012 at 03:46:04PM +0100, [email protected] wrote:
> Hello,I am trying to send a tuple to a method of a python class

   Also please don't send html-only mail.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
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] Python C API: Problem sending tuple to a method of a python Class

2012-01-10 Thread Martin v. Löwis 
Am 10.01.2012 18:15, schrieb Matt Joiner:
> I suspect it actually would fix the confusion. "dev" usually means
> development, not "core implementation development". People float past
> looking for dev help... python-dev. Python-list is a bit generic.

There is occasional confusion. More often, people think "there are the
folks who could actually answer my question, and nobody on python-list
answered, so I'll just ask there". We established to assume that they
are confused instead of deliberately breaking convention, which is a
polite way of pointing out that we really mean it.

IOW, I think it is all fine the way it is. Typically, somebody answers
quickly. In this case, *two* people answered the same, which
a) really gets the message through, and
b) suggests that people are not too tired in actually typing in
   this message every now and then.

Of course, pointing the OP to a more specific focused forum (which is
not always cython-users) is also kind.

Regards,
Martin
___
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] os.walk() with followlinks=False

2012-01-10 Thread Nick Coghlan 
When discussing http://bugs.python.org/issue13734, Charles-François
noted that when os.walk() is called with "followlinks=False", symlinks
to directories are still included in the "subdirs" list rather than
the "files" list.

This seems rather odd to me, so I'm asking here to see if there's a
specific rationale for it, or if it's just an artifact of the
implementation.

If it's the latter... could we change it for 3.3, or is that too
significant a breach of backwards compatibility?

Even if we can't change os.walk(), does os.walkfd() need to replicate
the annoying behaviour for consistency, or can it instead consider
such symlinks to be files rather than directories?

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] Python as a Metro-style App

2012-01-10 Thread Dino Viehland 
Martin wrote:
> Does that hold for all versions of the C runtime (i.e. is msvcr80.dll also
> exempt from the ban, or just the version that comes with VS 11)?

Just the VS 11 CRT is allowed.

> 
> > So to the extent that Python is just a C program the "port" should be
> > pretty easy and mostly involve disabling functionality that isn't
> > available at all to metro apps.
> 
> See the start of the thread: I tried to create a "WinRT Component DLL", and
> that failed, as VS would refuse to compile any C file in such a project. Not
> sure whether this is triggered by defining WINAPI_FAMILY=2, or any other
> compiler setting.
> 
> I'd really love to use WINAPI_FAMILY=2, as compiler errors are much easier
> to fix than verifier errors.

Let me see if I can try this.  Hopefully I still have my VM w/ this all setup 
and
I can see if I can get it building this way.  I can always ping some people on 
the
C++ team and ask them for help if I run into issues.  I'll give it a shot 
tomorrow 
and get back to you.

___
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] Python C API: Problem sending tuple to a method of a python Class

2012-01-10 Thread Eric Snow 
On Tue, Jan 10, 2012 at 6:09 PM, "Martin v. Löwis"  wrote:
> IOW, I think it is all fine the way it is. Typically, somebody answers
> quickly. In this case, *two* people answered the same, which
> a) really gets the message through, and
> b) suggests that people are not too tired in actually typing in
>   this message every now and then.

+1

-eric
___
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