Re: [Python-Dev] Semantics of __int__(), __index__()

2013-04-02 Thread Mark Dickinson 
On Tue, Apr 2, 2013 at 1:44 AM, Nick Coghlan  wrote:

> int() and operator.index() are both type coercion calls to produce true
> Python integers - they will never return a subclass, and this is both
> deliberate and consistent with all the other builtin types that accept an
> instance of themselves as input to the constructor.
>

That's good to hear.


> There's code in the slot wrappers so that if you return a non-int object
> from either __int__ or __index__, then the interpreter will complain about
> it, and if you return a subclass, it will be stripped back to just the base
> class.
>

Can you point me to that code?  All I could find was PyLong_Check calls (I
was looking for PyLong_CheckExact).

Mark
___
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] Semantics of __int__(), __index__()

2013-04-02 Thread Mark Dickinson 
On Tue, Apr 2, 2013 at 8:07 AM, Mark Dickinson  wrote:

> On Tue, Apr 2, 2013 at 1:44 AM, Nick Coghlan  wrote:
>
>> There's code in the slot wrappers so that if you return a non-int object
>> from either __int__ or __index__, then the interpreter will complain about
>> it, and if you return a subclass, it will be stripped back to just the base
>> class.
>>
>
> Can you point me to that code?  All I could find was PyLong_Check calls (I
> was looking for PyLong_CheckExact).
>

And indeed:

iwasawa:Objects mdickinson$ /opt/local/bin/python3.3
Python 3.3.0 (default, Sep 29 2012, 08:16:19)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
... def __int__(self):
... return True
... def __index__(self):
... return False
...
>>> a = A()
>>> int(a)
True
>>> import operator; operator.index(a)
False

Which means I have to do int(int(a)) to get the actual integer value.  Grr.

Mark
___
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] Semantics of __int__(), __index__()

2013-04-02 Thread Mark Shannon 



On 02/04/13 01:44, Nick Coghlan wrote:

On Mon, Apr 1, 2013 at 12:28 AM, Mark Dickinson mailto:[email protected]>> wrote:

As written, int_check would do the wrong thing for bools, too:  I
definitely want int(True) to be 1, not True.

For (2) and (4), it's not so clear.  Are there use-cases for an
__index__ return value that's not directly of type int?  I can't
think of any offhand.


int() and operator.index() are both type coercion calls to produce true
Python integers - they will never return a subclass, and this is both
deliberate and consistent with all the other builtin types that accept
an instance of themselves as input to the constructor. Passing a
subclass instance to the base class constructor is the way you convert a
subclass to an ordinary instance of the base class:


Unfortunately, that is not true :(

>>> class Int(int):
... def __int__(self):
... return self
...
>>> type(int(Int()))


Hence my original question: what *should* the semantics be?



 >>> for base in (str, bytes, bytearray, int, float, complex, dict,
tuple, list, set, frozenset):
... class subclass(base): pass
... print("'type(base(subclass()))' is", type(base(subclass(
...
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 
'type(base(subclass()))' is 

There's code in the slot wrappers so that if you return a non-int object
from either __int__ or __index__, then the interpreter will complain
about it, and if you return a subclass, it will be stripped back to just
the base class.

If the language and library reference aren't clear on this, it's a
documentation issue.

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] Semantics of __int__(), __index__()

2013-04-02 Thread Mark Dickinson 
On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon  wrote:

>
> Hence my original question: what *should* the semantics be?
>
>
I like Nick's answer to that: int *should* always return something of exact
type int.  Otherwise you're always left wondering whether you have to do
"int(int(x))", or perhaps even "int(int(int(x)))", to be absolutely sure of
getting an int.

The question is whether / how to fix the current behaviour, given that it
doesn't conform to those ideal semantics.

Mark
___
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] Semantics of __int__(), __index__()

2013-04-02 Thread Maciej Fijalkowski 
On Tue, Apr 2, 2013 at 10:53 AM, Mark Dickinson  wrote:
> On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon  wrote:
>>
>>
>> Hence my original question: what *should* the semantics be?
>>
>
> I like Nick's answer to that: int *should* always return something of exact
> type int.  Otherwise you're always left wondering whether you have to do
> "int(int(x))", or perhaps even "int(int(int(x)))", to be absolutely sure of
> getting an int.
>
> The question is whether / how to fix the current behaviour, given that it
> doesn't conform to those ideal semantics.
>
> Mark

My 2 cents here is that which one is called seems to be truly random.
Try looking into what builtin functions call (for example list.pop
calls __int__, who knew)
___
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] Semantics of __int__(), __index__()

2013-04-02 Thread Antoine Pitrou 
Le Tue, 2 Apr 2013 09:53:41 +0100,
Mark Dickinson  a écrit :
> On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon  wrote:
> 
> >
> > Hence my original question: what *should* the semantics be?
> >
> >
> I like Nick's answer to that: int *should* always return something of
> exact type int.  Otherwise you're always left wondering whether you
> have to do "int(int(x))", or perhaps even "int(int(int(x)))", to be
> absolutely sure of getting an int.

Agreed.

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] Semantics of __int__(), __index__()

2013-04-02 Thread Mark Dickinson 
On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski  wrote:

>
> My 2 cents here is that which one is called seems to be truly random.
> Try looking into what builtin functions call (for example list.pop
> calls __int__, who knew)
>

That sounds like a clear bug to me.  It should definitely be using
__index__.

Mark
___
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] Semantics of __int__(), __index__()

2013-04-02 Thread Mark Dickinson 
On Tue, Apr 2, 2013 at 10:02 AM, Mark Dickinson  wrote:

> On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski wrote:
>
>>
>> My 2 cents here is that which one is called seems to be truly random.
>> Try looking into what builtin functions call (for example list.pop
>> calls __int__, who knew)
>>
>
> That sounds like a clear bug to me.  It should definitely be using
> __index__.
>

Ah, and I see it *is* using `__index__` in Python 3; just not in Python
2.7.  It may be one of those Python 2 bugs that's not worth fixing because
the fix would do more harm (in the form of breakage of existing code) than
good.

-- 
Mark
___
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] relative import circular problem

2013-04-02 Thread Kristján Valur Jónsson 
Right, as I explained in my reply to Barry, I was imprecise.
But the “from X import Y” is the only way to invoke relative imports, where X 
can have leading dots.
This syntax places the constraint on X that Y is actually an attribute of X at 
this time, where
“import X.Y” does not.
So, even without the leading dots issue, they are not equivalent.  You run into 
the same
circular dependency problem without using relative imports if trying to use the
“from X import Y” where X is an absolute name.

K

From: [email protected] [mailto:[email protected]] On Behalf Of Brett Cannon
Sent: 1. apríl 2013 22:38
To: Kristján Valur Jónsson
Cc: [email protected]
Subject: Re: [Python-Dev] relative import circular problem



the latter works with partially initialized modules, but not the former, 
rendering two sibling modules unable to import each other using the relative 
syntax.

Clarification on terminology: the ``from .. import`` syntax is in no way 
relative. Relative imports use leading dots to specify relative offsets from 
your current position (i.e. as Barry said). It's more of a syntax for 
facilitating binding long names (e.g. foo.bar) to shorter names (bar). It's 
just unfortunate that it can lead to circular import issues when people start 
pulling in objects off of modules instead of modules alone.




as far as I know, relative imports are only supported using the former (import 
from) syntax.  Are there any plans to alleviate this by allowing proper 
relative imports?  After all, relative imports and packages go hand in hand.

No, there are no plans to either tweak ``from ... import`` statements nor 
introduce a new syntax to deal help alleviate circular imports.


___
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] relative import circular problem

2013-04-02 Thread Kristján Valur Jónsson 
It certainly affects the quality, yes.
I also understand why it happens:
When importing X.Y, Y isn't actually put into X's dict until it is fully 
initialized.  It is, however put temporarily in sys.modules["X.Y"]
hence, "import X.Y" on a partially initialized submodule Y will work, whereas 
"from X import Y" won't.

Fixing this within the "from X import Y" mechanism would add an additional 
strain on the already complex import protocol (as defined in pep 302), I think.
Which is why I wonder if the relative import syntax ought to be allowed for 
"import X" since that syntax does not involve a getattr.
("from X import Y" necessarily means strictly a getattr, since Y can both be 
any attribute of X, not just a submodule)

As for ways around this: Note that this is a language design question, not a 
software architecture one.  It is possible to work around these issues,
but it is not always nice.  Python is one of those languages that allow cyclic 
module dependencies and it is a very nice way to separate code
by functionality, if not by dependency.  It is one of the good things about 
Python and we should try to make sure that we allow such
architectural freedom to continue to work.

Also, relative imports are apparently falling into favor, having only 
marginally been accepted at the time of pep 328, so we should perhaps
find a way for these two things to co-exist :)

I'm not sure that
http://bugs.python.org/issue992389
warrants a fix.  This issue is about general attributes of a module.
In the general case, this is probably unfixable.  But access to a partially 
constructed
module hierarchy through the import mechanism ought to be possible.

K




From: Nick Coghlan [mailto:[email protected]]
Sent: 1. apríl 2013 22:53
To: Kristján Valur Jónsson
Cc: [email protected]
Subject: Re: [Python-Dev] relative import circular problem


with partially initialized modules, but not the former, rendering two sibling 
modules unable to import each other using the relative syntax.

This is really a quality-of-implementation issue in the import system rather 
than a core language design problem. It's just that those of us with the 
knowledge and ability to fix it aren't inclined to do so because circular 
imports usually (although not quite always) indicate a need to factor some 
common code out into a third support module imported by both of the original 
modules. At that point, the code is cleaner and more decoupled, and the uneven 
circular import support ceases to be a problem for that application.
If you're interested in digging further, see http://bugs.python.org/issue992389 
(this should also be a *lot* easier to fix now we're using importlib than it 
ever would have been while we were

___
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] relative import circular problem

2013-04-02 Thread Kristján Valur Jónsson 

> -Original Message-
> From: Python-Dev [mailto:python-dev-
> [email protected]] On Behalf Of Barry Warsaw
> Sent: 1. apríl 2013 22:16
> To: [email protected]
> Subject: Re: [Python-Dev] relative import circular problem
> 
> On Apr 01, 2013, at 08:20 PM, Kristján Valur Jónsson wrote:
> 
> >The relative import syntax
> >
> > (from foo import bar) is a getattr type of lookup (i.e. import foo,
> > then get attr from it).
> >
> >This is in contrast with absolute import
> >
> >  import foo.bar  (get the module foo.bar from sys.modules or import
> > it)
> >
> >  bar = foo.bar
> 
> I always thought of both syntaxes as absolute imports because they both
> name the full dotted path to the module you want.  This contrasts with true
> PEP
> 328 relative imports such as:
> 
> from ..foo import bar
> 
Right, the example I gave was not a relative import but an absolute one, 
relative imports always
starting with a dot.  I should have been more clear.
However, relative imports can _only_ be performed using the "from X import Y 
syntax" (http://www.python.org/dev/peps/pep-0328/#id3)
and so, when one wishes to use relative imports, the parent module must be 
fully initialized with the child module as an attribute.
importing with the "import X.Y" does not appear to have this restriction.

> I personally dislike PEP 328 relative imports, since they seem fragile, but 
> that's a different discussion.
Yes.  I find them very useful.  In our environment, we tend to write packages 
that then go into
different places.  Using relative imports allows us the freedom to move 
packages around and rename
them, for example, make a package a sub-package of another, and do this 
differently for different products, while still sharing code.
A package can thus refer to internals of itself, without knowing its own name, 
or absolute path.  This is really useful.

Consider this a property of Python-based "products", with a custom assembly of 
source code, as opposed to publicly
available packages that always install into the sys.path

Cheers,
K
___
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] relative import circular problem

2013-04-02 Thread Antoine Pitrou 
Le Tue, 2 Apr 2013 09:28:17 +,
Kristján Valur Jónsson  a écrit :
> Right, as I explained in my reply to Barry, I was imprecise.
> But the “from X import Y” is the only way to invoke relative imports,
> where X can have leading dots. This syntax places the constraint on X
> that Y is actually an attribute of X at this time, where “import X.Y”
> does not. So, even without the leading dots issue, they are not
> equivalent.  You run into the same circular dependency problem
> without using relative imports if trying to use the “from X import Y”
> where X is an absolute name.

I agree with Kristjan, it is rather annoying.
And it also makes explicit relative imports harder to sell to people
used to the implicit relative import style, since the latter works well
in such circumstances.

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] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

2013-04-02 Thread Steve Dower 
> python -m pyzaa pack [-o path/name] [-m module.submodule:callable] [-c] [-w] 
> [-p interpreter] directory:
>
>ZIP the contents of directory as directory.pyz or [-w] directory.pyzw. 
> Adds the executable flag to the archive.
>
> ...
>
>-p interpreter include #!interpreter as the first line of the archive

What happens when -p is omitted? I'd hope it would add the interpreter used to 
create the zip (or at least the major version), but that may not be ideal for 
some reason that I haven't thought of yet.

Everything else looks great. I'm really looking forward to this.

Cheers,
Steve

___
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] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

2013-04-02 Thread Brett Cannon 
On Tue, Apr 2, 2013 at 1:20 PM, Steve Dower wrote:

> > python -m pyzaa pack [-o path/name] [-m module.submodule:callable] [-c]
> [-w] [-p interpreter] directory:
> >
> >ZIP the contents of directory as directory.pyz or [-w]
> directory.pyzw. Adds the executable flag to the archive.
> >
> > ...
> >
> >-p interpreter include #!interpreter as the first line of the archive
>
> What happens when -p is omitted? I'd hope it would add the interpreter
> used to create the zip (or at least the major version), but that may not be
> ideal for some reason that I haven't thought of yet.
>

Question is whether ``/usr/bin/python3.3`` is better or ``/usr/bin/env
python3.3``. I vote for the latter since it gets you the right thing
without having to care about whether the interpreter moved or is being
hidden by a user-installed interpreter.

-Brett


>
> Everything else looks great. I'm really looking forward to this.
>
> Cheers,
> Steve
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
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 (3.3): Whatsnew typo

2013-04-02 Thread Eric V. Smith 
On 4/2/2013 5:15 PM, Eric V. Smith wrote:
> On 10/3/2012 8:59 PM, jesus.cea wrote:
>>  
>> -Solaris and derived platforms have a new class :class:`select.devpoll`
>> -for high performance asyncronous sockets via :file:`/dev/poll`.
>> +Solaris and derivatives platforms have a new class :class:`select.devpoll`
>> +for high performance asynchronous sockets via :file:`/dev/poll`.
> 
> That should be "Solaris and derivative platforms ...".
> 

Ignore that. My mailer went haywire and was showing ancient emails as
recent and unread. Sorry for the noise.

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

Re: [Python-Dev] [Python-checkins] cpython (3.3): Whatsnew typo

2013-04-02 Thread Eric V. Smith 
On 10/3/2012 8:59 PM, jesus.cea wrote:
>  
> -Solaris and derived platforms have a new class :class:`select.devpoll`
> -for high performance asyncronous sockets via :file:`/dev/poll`.
> +Solaris and derivatives platforms have a new class :class:`select.devpoll`
> +for high performance asynchronous sockets via :file:`/dev/poll`.

That should be "Solaris and derivative platforms ...".

___
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] relative import circular problem

2013-04-02 Thread Greg Ewing 

Kristján Valur Jónsson wrote:

However, relative imports can _only_ be performed using the "from X import Y 
syntax"


This seems like a legitimate complaint on its own, regardless
of the circular import issue. The principle of least surprise
suggests that relative imports should be possible using either
syntax.

I'm guessing the reason that 'import' doesn't support relative
imports is that it's not clear what name to bind the imported
module to.

There are a couple of ways that this could be resolved. One
would be to use the name resulting from stripping off the
leading dots, so that

   import .foo

would bind the module to the name 'foo'. Another would be
to always require an 'as' clause in this case, so that you
would have to write'

   import .foo as foo

--
Greg
___
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] could gevent be apart the standard Python library in future ?

2013-04-02 Thread iMath 
Hi, 
It will be my first post here.
 
 
 
could gevent be apart  the standard Python library in future ?___
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] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

2013-04-02 Thread Stefan Behnel 
Brett Cannon, 02.04.2013 19:28:
> On Tue, Apr 2, 2013 at 1:20 PM, Steve Dower wrote:
> 
>>> python -m pyzaa pack [-o path/name] [-m module.submodule:callable] [-c]
>> [-w] [-p interpreter] directory:
>>>
>>>ZIP the contents of directory as directory.pyz or [-w]
>> directory.pyzw. Adds the executable flag to the archive.
>>>
>>> ...
>>>
>>>-p interpreter include #!interpreter as the first line of the archive
>>
>> What happens when -p is omitted? I'd hope it would add the interpreter
>> used to create the zip (or at least the major version), but that may not be
>> ideal for some reason that I haven't thought of yet.
> 
> Question is whether ``/usr/bin/python3.3`` is better or ``/usr/bin/env
> python3.3``. I vote for the latter since it gets you the right thing
> without having to care about whether the interpreter moved or is being
> hidden by a user-installed interpreter.

It can't work properly from within a virtualenv when you write
"/usr/bin/python", so using "/usr/bin/env" instead is actually required.

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] could gevent be apart the standard Python library in future ?

2013-04-02 Thread Maciej Fijalkowski 
On Wed, Apr 3, 2013 at 4:42 AM, iMath <[email protected]> wrote:
> Hi,
> It will be my first post here.
>
>
>
> could gevent be apart  the standard Python library in future ?

Hi.

Such question generally belongs to python-ideas. To start with you
need to restart the question whether greenlets module should be a part
of the standard library (and please do it on the python-ideas mailing
list).

Cheers and welcome,
fijal
___
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