Nick> We fixed the module names that used mixed case - the amount of
Nick> work that turned out to be involved in just doing that much for
Nick> PEP 3108 makes me shudder at the thought of trying to fix all of
Nick> the standard library APIs that currently don't follow the style
On 5/31/08, Mark Hammond <[EMAIL PROTECTED]> wrote:
> So it seems that maybe simply "setExecutable()" isn't the correct
> abstraction here, but maybe a "factory" approach, so the entire process
> creation mechanism can be replaced rather than just the name of the
> executable to spawn?
Indeed.
[EMAIL PROTECTED] wrote:
Nick> We fixed the module names that used mixed case - the amount of
Nick> work that turned out to be involved in just doing that much for
Nick> PEP 3108 makes me shudder at the thought of trying to fix all of
Nick> the standard library APIs that currently
On Sat, May 31, 2008 at 6:31 PM, r.m.oudkerk <[EMAIL PROTECTED]> wrote:
> On 31/05/2008, Paul Moore <[EMAIL PROTECTED]> wrote:
>> 2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>:
>>> I'm not sure if there will be any side affects to modifying
>>> sys.executable though. Should this be the official wa
>> If the 3.0 API of a module is going to involve breakage which
>> requires authors to update their applications wouldn't this be a good
>> time to PEP-8-ify the module? (Not suggesting that threading would
>> fall into this category.)
Nick> Updating application code to deal
Paul Moore wrote:
Wasn't there some talk of changing modules to use PEP 8 conventions
(lowercase_with_underscore) as part of the Python 3.0 conversion? Did
that ever happen?
We fixed the module names that used mixed case - the amount of work that
turned out to be involved in just doing that mu
2008/5/31 r. m. oudkerk <[EMAIL PROTECTED]>:
> I am certainly open to using lowercase/lower_case_with_underscores for
> all functions/methods except for Process's methods and possibly
> currentProcess(), but I would like some feed back on that.
I dislike mixedCase, but consistency with the rest of
> 2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>:
> > I'm not sure if there will be any side affects to modifying
> > sys.executable though. Should this be the official way of supporting
> > embedded interpreters or should there be a
> > multiprocessing.setExecutable() method?
>
> +1 for setExecut
On 31/05/2008, Paul Moore <[EMAIL PROTECTED]> wrote:
> 2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>:
>> I'm not sure if there will be any side affects to modifying
>> sys.executable though. Should this be the official way of supporting
>> embedded interpreters or should there be a
>> multiprocess
2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>:
> I'm not sure if there will be any side affects to modifying
> sys.executable though. Should this be the official way of supporting
> embedded interpreters or should there be a
> multiprocessing.setExecutable() method?
+1 for setExecutable (I'd pref
On Fri, May 30, 2008 at 9:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> py2exe is explicitly supported (via the freezeSupport() call). That may work
> for the embedded case as well, or it may be something that can be addressed
> by modifying sys.executable.
Thanks for the tip Nick. Adding the f
Thomas Heller wrote:
Jesse Noller schrieb:
On Fri, May 30, 2008 at 2:19 AM, Farshid Lashkari <[EMAIL PROTECTED]> wrote:
On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote:
I would like to renew the discussion now that "there is a PEP" to see
if there are any outstanding t
Jesse Noller schrieb:
> On Fri, May 30, 2008 at 2:19 AM, Farshid Lashkari <[EMAIL PROTECTED]> wrote:
>> On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote:
>>> I would like to renew the discussion now that "there is a PEP" to see
>>> if there are any outstanding things people
On Fri, May 30, 2008 at 2:19 AM, Farshid Lashkari <[EMAIL PROTECTED]> wrote:
> On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote:
>> I would like to renew the discussion now that "there is a PEP" to see
>> if there are any outstanding things people would like to get resolved.
On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote:
> I would like to renew the discussion now that "there is a PEP" to see
> if there are any outstanding things people would like to get resolved.
> I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback
> both
I would like to renew the discussion now that "there is a PEP" to see
if there are any outstanding things people would like to get resolved.
I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback
both here and elsewhere that people would rather see this in sooner in
some form, rath
On Thu, May 29, 2008 at 3:18 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jesse Noller wrote:
>> Georg kindly published the PEP I submitted last night to the PEP site:
>>
>> http://www.python.org/dev/peps/pep-0371/
>>
>> This PEP includes some of the previous discussion on the processing
>> module
On Thu, May 29, 2008 at 9:39 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Could you possibly extend the PEP to also document performance when, for
> instance, passing "big" objects via a queue, or sending "Events" back,
> testing "thread.isAlive()",
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Could you possibly extend the PEP to also document performance when, for
instance, passing "big" objects via a queue, or sending "Events" back,
testing "thread.isAlive()", and stuff like that?. What about mutexes?
(not to protect shared objects, but f
On Thu, May 29, 2008 at 6:22 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>>
>> Jesse Noller wrote:
>> > Georg kindly published the PEP I submitted last night to the PEP site:
>> >
>> > http://www.python.org/dev/peps/pep-0371/
>> >
>> > This PEP includes some of the previous d
Nick Coghlan wrote:
Jesse Noller wrote:
> Georg kindly published the PEP I submitted last night to the PEP site:
>
> http://www.python.org/dev/peps/pep-0371/
>
> This PEP includes some of the previous discussion on the processing
> module's inclusion, and I hope clears up/clarifies some of the
>
Jesse Noller wrote:
> Georg kindly published the PEP I submitted last night to the PEP site:
>
> http://www.python.org/dev/peps/pep-0371/
>
> This PEP includes some of the previous discussion on the processing
> module's inclusion, and I hope clears up/clarifies some of the
> goals/non goals and i
22 matches
Mail list logo
