Hello,
>> async.submit_work(func, args, kwds, callback=None, errback=None)
>>
>> How do you implement arguments passing and return value?
>>
>> e.g. let's say I pass a list as argument: how do you iterate on the
>> list from the worker thread without modifying the backing objects for
>> refcounts
Guido van Rossum, 04.04.2013 23:14:
> On Thu, Apr 4, 2013 at 1:50 PM, Tim Delaney wrote:
>> I fall into:
>>
>> 1. int(), float(), str() etc should return that exact class (and
>> operator.index() should return exactly an int).
>>
>> 2. It could sometimes be useful for __int__() and __index__() to r
On 04/03/2013 09:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
It's analogous to all
the other built-in types-as-functions, so int() calls __int__() which
must
return a concrete integer.
Why must it? I think that's the claim which must be justified, not
just taken
as
On 05/04/13 01:23, Oscar Benjamin wrote:
The reason for calling int(obj) is to get an object that is precisely
of type int. When I call this I do not want any modified or additional
methods or data attached to the resulting object.
When I call int(), I'm expecting an int. That includes well-be
http://bugs.python.org/issue17636
On Thu, Apr 4, 2013 at 8:03 PM, Brett Cannon wrote:
>
> On Apr 4, 2013 6:47 PM, "Guido van Rossum" wrote:
> >
> > +1 on Brett and PJE just doing this.
>
> I'll file a bug when I get home.
>
> -brett
>
> >
> > On Thu, Apr 4, 2013 at 3:38 PM, Brett Cannon wrote
On 5 Apr 2013 01:07, "Chris Angelico" wrote:
>
> On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote:
> > On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote:
> >> Is there any argument that I can pass to Foo() to get back a Bar()?
> >> Would anyone expect there to be one? Sure, I could over
On Apr 4, 2013 6:47 PM, "Guido van Rossum" wrote:
>
> +1 on Brett and PJE just doing this.
I'll file a bug when I get home.
-brett
>
> On Thu, Apr 4, 2013 at 3:38 PM, Brett Cannon wrote:
> >
> >
> >
> > On Thu, Apr 4, 2013 at 5:00 PM, PJ Eby wrote:
> >>
> >> On Thu, Apr 4, 2013 at 4:42 PM, Gu
+1 on Brett and PJE just doing this.
On Thu, Apr 4, 2013 at 3:38 PM, Brett Cannon wrote:
>
>
>
> On Thu, Apr 4, 2013 at 5:00 PM, PJ Eby wrote:
>>
>> On Thu, Apr 4, 2013 at 4:42 PM, Guido van Rossum wrote:
>> > I do think it would be fine if "from a import b" returned the
>> > attribute 'b' of m
On Thu, Apr 4, 2013 at 5:00 PM, PJ Eby wrote:
> On Thu, Apr 4, 2013 at 4:42 PM, Guido van Rossum wrote:
> > I do think it would be fine if "from a import b" returned the
> > attribute 'b' of module 'a' if it exists, and otherwise look for
> > module 'a.b' in sys.modules.
>
> Technically, it alre
On 03Apr2013 12:12, Greg Ewing wrote:
| 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, [...]
| There are a couple of ways that this could be resolved. One
| would be to u
On Thu, Apr 4, 2013 at 1:50 PM, Tim Delaney wrote:
> I fall into:
>
> 1. int(), float(), str() etc should return that exact class (and
> operator.index() should return exactly an int).
>
> 2. It could sometimes be useful for __int__() and __index__() to return a
> subclass of int.
>
> So, for the
On 5 April 2013 02:16, Ethan Furman wrote:
> On 04/04/2013 08:01 AM, Chris Angelico wrote:
>
>> On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum
>> wrote:
>>
>>> On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote:
>>>
Is there any argument that I can pass to Foo() to get back a Bar()?
>>
On Thu, Apr 4, 2013 at 4:42 PM, Guido van Rossum wrote:
> I do think it would be fine if "from a import b" returned the
> attribute 'b' of module 'a' if it exists, and otherwise look for
> module 'a.b' in sys.modules.
Technically, it already does that -- but inside of __import__, not in
the IMPOR
Thanks for the insight. That could indeed be done and I would
encourage someone to come up with a fix.
FWIW there is another difference between the two forms -- "from a
import b" allows b to be any attribute of a, whereas "import a.b"
requires b to be a submodule of a. I don't want to compromise o
On Thu, Apr 4, 2013 at 11:17 AM, Guido van Rossum wrote:
> I don't really see what we could change to avoid breaking code in any
> particular case
Actually, the problem has *nothing* to do with circularity per se;
it's that "import a.b" and "from a import b" behave differently in
terms of how the
Hi Charles-François,
On Thu, Apr 04, 2013 at 01:18:58AM -0700, Charles-François Natali wrote:
> Just a quick implementation question (didn't have time to read through
> all your emails :-)
>
> async.submit_work(func, args, kwds, callback=None, errback=None)
>
> How do you implement arguments pas
Redirecting to python-ideas.
On Thu, Apr 4, 2013 at 9:26 AM, Richard Oudkerk wrote:
> On 04/04/2013 4:17pm, Guido van Rossum wrote:
>>
>> I don't really see what we could change to avoid breaking code in any
>> particular case -- the burden is up to the library to do it right. I
>> don't see a re
On 04/04/2013 4:17pm, Guido van Rossum wrote:
I don't really see what we could change to avoid breaking code in any
particular case -- the burden is up to the library to do it right. I
don't see a reason to forbid any of this either.
How about having a form of relative import which only works f
In article <515d760d.50...@googlemail.com>,
Julian Taylor wrote:
> The values on macos for these variables still look wrong in 3.3.1rc1:
>
> ./configure --prefix=/Users/jtaylor/tmp/py3.3.1 --enable-shared
> on macosx-10.8-x86_64
>
> sys.version_info(major=3, minor=3, micro=1, releaselevel='cand
On Thu, Apr 4, 2013 at 10:42 AM, Antoine Pitrou wrote:
> Le Thu, 4 Apr 2013 06:57:14 +0200,
> Charles-François Natali a écrit :
> > > Are you planning to cover the code quality of the interpreter itself
> > > too? I've been recently reading through the cert.org secure coding
> > > practice recom
On 04/04/2013 08:01 AM, Chris Angelico wrote:
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote:
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote:
Is there any argument that I can pass to Foo() to get back a Bar()?
Would anyone expect there to be one? Sure, I could override __new__ t
Le Fri, 5 Apr 2013 01:47:45 +1100,
Chris Angelico a écrit :
>
> class Foo:
> pass
>
> class Bar(Foo):
> pass
>
> Is there any argument that I can pass to Foo() to get back a Bar()?
> Would anyone expect there to be one? Sure, I could override __new__ to
> do stupid things, but in terms
On Thu, Apr 4, 2013 at 8:01 AM, Chris Angelico wrote:
> On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote:
> > On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote:
> >> Is there any argument that I can pass to Foo() to get back a Bar()?
> >> Would anyone expect there to be one? Sure, I co
On Thu, Apr 4, 2013 at 2:36 AM, Kristján Valur Jónsson <
krist...@ccpgames.com> wrote:
[...]
> There can be good and valid reasons to put things that depend on each
> other in separate modules, for example when trying to separate modules by
> functionality or simply when splitting a long file into
On 2013-04-04, at 17:01 , Chris Angelico wrote:
> On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote:
>> On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote:
>>> Is there any argument that I can pass to Foo() to get back a Bar()?
>>> Would anyone expect there to be one? Sure, I could overr
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote:
> On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote:
>> Is there any argument that I can pass to Foo() to get back a Bar()?
>> Would anyone expect there to be one? Sure, I could override __new__ to
>> do stupid things, but in terms of log
On 2013-04-04, at 16:47 , Chris Angelico wrote:
> Sure, I could override __new__ to do stupid things
Or to do perfectly logical and sensible things, such as implementing
"cluster classes" or using the base class as a factory of sorts.
> in terms of logical expectations, I'd expect
> that Foo(x) w
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote:
> On Fri, Apr 5, 2013 at 1:23 AM, Oscar Benjamin
> wrote:
> > The reason for calling int(obj) is to get an object that is precisely
> > of type int. When I call this I do not want any modified or additional
> > methods or data attached to the
Am 04.04.2013 16:47, schrieb Chris Angelico:
> On Fri, Apr 5, 2013 at 1:23 AM, Oscar Benjamin
> wrote:
>> The reason for calling int(obj) is to get an object that is precisely
>> of type int. When I call this I do not want any modified or additional
>> methods or data attached to the resulting obj
On Fri, Apr 5, 2013 at 1:23 AM, Oscar Benjamin
wrote:
> The reason for calling int(obj) is to get an object that is precisely
> of type int. When I call this I do not want any modified or additional
> methods or data attached to the resulting object.
There's something I'm fundamentally not unders
Le Thu, 4 Apr 2013 06:57:14 +0200,
Charles-François Natali a écrit :
> > Are you planning to cover the code quality of the interpreter itself
> > too? I've been recently reading through the cert.org secure coding
> > practice recommendations and was wondering if there has is any
> > ongoing effort
On Thu, Apr 4, 2013 at 2:45 PM, Ian Cordasco wrote:
> Hey Alfredo,
>
> We do not currently have any tools to do that, but it would definitely
> be something interesting to discuss and maybe design on the list. I'm
> sure there are static analysis tools for the C part and I'm sure we as
> a communi
On 4 April 2013 10:39, Hrvoje Niksic wrote:
>
>> On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic
>> wrote:
>>>
>>> It seems like a good feature that an __int__ implementation can choose to
>>> return an int subclass with additional (and optional) information. After
>>> all, int subclass instances s
On 4 Apr 2013 19:37, "Kristján Valur Jónsson" wrote:
>
>
>
> > -Original Message-
> > From: Eric Snow [mailto:ericsnowcurren...@gmail.com]
> > Sent: 4. apríl 2013 04:57
> > > imported by both of the original modules. At that point, the code is
> > > cleaner and more decoupled, and the unev
The values on macos for these variables still look wrong in 3.3.1rc1:
./configure --prefix=/Users/jtaylor/tmp/py3.3.1 --enable-shared
on macosx-10.8-x86_64
sys.version_info(major=3, minor=3, micro=1, releaselevel='candidate',
serial=1)
SO .so
EXT_SUFFIX .so
SHLIB_SUFFIX 0
the only correct on
On Wed, Apr 3, 2013 at 9:21 PM, Alfredo Solano Martínez wrote:
> Hi,
>
> Are you planning to cover the code quality of the interpreter itself
> too? I've been recently reading through the cert.org secure coding
> practice recommendations and was wondering if there has is any ongoing
> effort to pe
> -Original Message-
> From: Eric Snow [mailto:ericsnowcurren...@gmail.com]
> Sent: 4. apríl 2013 04:57
> > 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 applica
Eric Snow:
On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic wrote:
It seems like a good feature that an __int__ implementation can choose to
return an int subclass with additional (and optional) information. After
all, int subclass instances should be usable everywhere where ints are,
including in
Just a quick implementation question (didn't have time to read through
all your emails :-)
async.submit_work(func, args, kwds, callback=None, errback=None)
How do you implement arguments passing and return value?
e.g. let's say I pass a list as argument: how do you iterate on the
list from the w
39 matches
Mail list logo
