On Wed, Apr 3, 2013 at 4:42 AM, iMath <2281570...@qq.com> 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 modu
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 execu
Hi,
It will be my first post here.
could gevent be apart the standard Python library in future ?___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/optio
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
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
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:`selec
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.
> >
> > ...
> 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 li
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
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Barry Warsaw
> Sent: 1. apríl 2013 22:16
> To: python-dev@python.org
> Subject: Re: [Python-Dev] relative import circular problem
>
> On Apr 01, 2013, at 08:20 PM, Kristján
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
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
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)
>>
>
>
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
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
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
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 ev
On 02/04/13 01:44, Nick Coghlan wrote:
On Mon, Apr 1, 2013 at 12:28 AM, Mark Dickinson mailto:dicki...@gmail.com>> 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 u
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 subcl
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 themselve
20 matches
Mail list logo
