2013/8/2 Victor Stinner :
> On Windows, inheritable handles (including open files) are still
> inherited when a standard stream is overriden in the subprocess module
> (default value of close_fds is set to False in this case). This issue
> cannot be solved (at least, I don't see how): it is a limit
2013/8/2 Victor Stinner :
> 2013/7/28 Antoine Pitrou :
>>> (A) How should we support support where os.set_inheritable() is not
>>> supported? Can we announce that os.set_inheritable() is always
>>> available or not? Does such platform exist?
>>
>> FD_CLOEXEC is POSIX:
>> http://pubs.opengroup.org/o
Steven D'Aprano wrote:
> Lambda is still useful for the reason lambda has always been useful: it is
> an expression, not a statement, so you can embed it directly where needed.
are there some possibilities to change def to an expression? do I need to
wait 'till python9k?
yes, this brings to the
2013/7/30 Antoine Pitrou :
> Le Tue, 30 Jul 2013 09:09:38 +0200,
> Charles-François Natali a écrit :
>> This looks more and more like PEP 433 :-)
>>
>> And honestly, when I think about it, I think that this whole mess is a
>> solution looking for a problem.
>> If we don't want to inherit file desc
2013/7/28 Antoine Pitrou :
>> (A) How should we support support where os.set_inheritable() is not
>> supported? Can we announce that os.set_inheritable() is always
>> available or not? Does such platform exist?
>
> FD_CLOEXEC is POSIX:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcn
2013/7/30 Victor Stinner :
> I would be nice to have a "pass_handles" on Windows.
I'm not sure that it's possible to implement this atomically. It's
probably better to leave the application to choose how the inheritance
is defined.
Example:
for handle in handles:
os.set_inheritable(handle, T
2013/7/30 Richard Oudkerk :
> The documentation for STARTUPINFO says this about STARTF_USESTDHANDLES:
>
> If this flag is specified when calling one of the process creation
> functions, the handles must be inheritable and the function's
> bInheritHandles parameter must be set to TRUE.
>
>
On 2 Aug 2013 01:18, "Alexander Belopolsky"
wrote:
>
>
> On Thu, Aug 1, 2013 at 10:21 AM, R. David Murray
wrote:
>>
>> > I'm guessing it's short enough you can say you tried, but long
>> > enough to annoy traditionalists anyway.
>> >
>> > I'm annoyed already. :-)
>>
>> +1 :)
>
>
> +1 :)
>
> I re
On Thu, Aug 1, 2013 at 3:44 PM, Brian Curtin wrote:
> On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy wrote:
>> On 8/1/2013 11:03 AM, Alexander Shorin wrote:
>>>
>>> ...and, if so, why lambda's?(: Without backward compatibility point I
>>> see that they are getting "unofficially" deprecated and their
On 8/1/2013 11:35 AM, Alexander Belopolsky wrote:
Here is one use-case where .. = lambda .. cannot be replaced with def ..
op['add'] = lambda x,y: x+y
op['mul'] = lambda x, y: x*y
Yes, you are binding the functions to named slots, not to names, so not
covered by the PEP. Once might still wa
On Thu, Aug 1, 2013 at 4:29 PM, Terry Reedy wrote:
> def f(x): return 2*x
> f = lambda x: 2*x
>
Am I the only one who finds the second line above much more readable than
the first? The def statement is not intended to be written in one line.
The readability suffers because the argument is sepa
On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy wrote:
> On 8/1/2013 11:03 AM, Alexander Shorin wrote:
>>
>> ...and, if so, why lambda's?(: Without backward compatibility point I
>> see that they are getting "unofficially" deprecated and their usage is
>> dishonoured.
>
>
> Please stop both the top-po
On 8/1/2013 11:03 AM, Alexander Shorin wrote:
...and, if so, why lambda's?(: Without backward compatibility point I
see that they are getting "unofficially" deprecated and their usage is
dishonoured.
Please stop both the top-posting and the FUD.
--
Terry Jan Reedy
On 8/1/2013 10:48 AM, Alexander Shorin wrote:
I understand this, but I'm a bit confused about fate of lambdas with
such guideline since I see no more reasons to use them with p.9
statement: long lines, code duplicate, no mock and well tests etc. -
all these problems could be solved with assigning
On 8/1/2013 10:34 AM, Alexander Shorin wrote:
Hi Nick,
On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan wrote:
9. Explicit guideline not to assign lambdas to names (use def, that's
what it's for)
Even for propose to fit chars-per-line limit
def f(x): return 2*x
f = lambda x: 2*x
Three spaces
* Stephen J. Turnbull wrote:
> Chris Angelico writes:
> > On Thu, Aug 1, 2013 at 5:58 PM, Alexander Shorin
wrote:
> > > fun = lambda i: i[1]
> > > for key, items in groupby(sorted(items, key=fun), key=fun):
> > > print(key, ':', list(items))
> >
> > I'd do a direct translation to def her
Chris Angelico writes:
> On Thu, Aug 1, 2013 at 5:58 PM, Alexander Shorin wrote:
> > fun = lambda i: i[1]
> > for key, items in groupby(sorted(items, key=fun), key=fun):
> > print(key, ':', list(items))
>
> I'd do a direct translation to def here:
>
> def fun(i): return i[1]
> for key
On Thu, Aug 1, 2013 at 12:58 PM, Alexander Shorin wrote:
> Hi Steven,
>
> On Thu, Aug 1, 2013 at 7:06 PM, Steven D'Aprano
> wrote:
> > Hi Alexander,
> >
> > On 02/08/13 00:48, Alexander Shorin wrote:
> >>
> >> Hi Ronald,
> >>
> >> I understand this, but I'm a bit confused about fate of lambdas w
On Thu, Aug 1, 2013 at 5:58 PM, Alexander Shorin wrote:
> fun = lambda i: i[1]
> for key, items in groupby(sorted(items, key=fun), key=fun):
> print(key, ':', list(items))
I'd do a direct translation to def here:
def fun(i): return i[1]
for key, items in groupby(sorted(items, key=fun), key=fun
Hi Steven,
On Thu, Aug 1, 2013 at 7:06 PM, Steven D'Aprano wrote:
> Hi Alexander,
>
> On 02/08/13 00:48, Alexander Shorin wrote:
>>
>> Hi Ronald,
>>
>> I understand this, but I'm a bit confused about fate of lambdas with
>> such guideline since I see no more reasons to use them with p.9
>> statem
On Aug 01, 2013, at 11:52 AM, R. David Murray wrote:
>So as we edit the docs, we re-wrap. Just like we do with the legacy
>code :)
+1!
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
On Thu, 01 Aug 2013 11:35:38 -0400, Barry Warsaw wrote:
> So I would greatly prefer that stdlib files be kept to the 79 character
> limit. I see most violations of this in the library documents, but especially
> there, paragraphs should be wrapped to 79 characters, and can easily be done
> withou
On Thu, Aug 1, 2013 at 11:03 AM, Alexander Shorin wrote:
> ...and, if so, why lambda's?(: Without backward compatibility point I
> see that they are getting "unofficially" deprecated and their usage is
> dishonored.
>
>
Here is one use-case where .. = lambda .. cannot be replaced with def ..
op
On Aug 01, 2013, at 11:05 AM, Alexander Belopolsky wrote:
>I will start experimenting with 100-char limit, but I think it is still too
>wide for auto-wrapped text. Maybe we should have a stronger
>recommendation to keep 80-char limit for docstrings and other embedded
>text. It is OK to have an
Le Thu, 01 Aug 2013 17:03:03 +0200,
"Martin v. Löwis" a écrit :
> Am 30.07.13 23:32, schrieb Antoine Pitrou:
> > - it is held alive by a C extension: the main example is the locale
> > module, which is held alive by _io and in turn keeps alive other
> > Python modules (such as collections or r
On Thu, Aug 1, 2013 at 10:21 AM, R. David Murray wrote:
> > I'm guessing it's short enough you can say you tried, but long
> > enough to annoy traditionalists anyway.
> >
> > I'm annoyed already. :-)
>
> +1 :)
+1 :)
I recently gave up and reset default auto-wrap margin to 120 locally. This
ch
On 1 Aug, 2013, at 17:03, Alexander Shorin wrote:
> ...and, if so, why lambda's?(: Without backward compatibility point I
> see that they are getting "unofficially" deprecated and their usage is
> dishonoured.
They are still usefull for simple functions that you use in one place,
such as the ke
Le Thu, 1 Aug 2013 23:21:49 +1000,
Nick Coghlan a écrit :
> On 1 August 2013 23:10, Antoine Pitrou wrote:
> > Le Thu, 1 Aug 2013 22:44:12 +1000,
> > Nick Coghlan a écrit :
> >> 4. Lines up to 99 characters are now permitted (but 79 is still the
> >> preferred limit)
> >
> > Something magic about
On Thu, 01 Aug 2013 16:53:16 +0200, Ronald Oussoren
wrote:
> On 1 Aug, 2013, at 16:48, Alexander Shorin wrote:
> > I understand this, but I'm a bit confused about fate of lambdas with
> > such guideline since I see no more reasons to use them with p.9
> > statement: long lines, code duplicate, n
Hi Alexander,
On 02/08/13 00:48, Alexander Shorin wrote:
Hi Ronald,
I understand this, but I'm a bit confused about fate of lambdas with
such guideline since I see no more reasons to use them with p.9
statement: long lines, code duplicate, no mock and well tests etc. -
all these problems could
...and, if so, why lambda's?(: Without backward compatibility point I
see that they are getting "unofficially" deprecated and their usage is
dishonoured.
--
,,,^..^,,,
On Thu, Aug 1, 2013 at 6:53 PM, Ronald Oussoren wrote:
>
> On 1 Aug, 2013, at 16:48, Alexander Shorin wrote:
>
>> Hi Ronald,
>
> http://mail.python.org/pipermail/python-list/2013-July/653046.html
One correspondent objected that I was artificial biasing my histogram
because wrapped lines are, more-or-less by definition, going to be <
80 characters. Off-list I responded with a modified version of my
graph where I eliminate
Am 30.07.13 23:32, schrieb Antoine Pitrou:
> - it is held alive by a C extension: the main example is the locale
> module, which is held alive by _io and in turn keeps alive other
> Python modules (such as collections or re).
If the _locale module would use PEP 3121 (issue15662), this problem
On 01/08/13 22:44, Nick Coghlan wrote:
With feedback from Guido, Barry, Raymond and others, I have updated
PEP 8 to better describe our current development practices. It started
as an update to describe the different between public and internal
interfaces and to advise against using wildcard impo
On 1 Aug, 2013, at 16:48, Alexander Shorin wrote:
> Hi Ronald,
>
> I understand this, but I'm a bit confused about fate of lambdas with
> such guideline since I see no more reasons to use them with p.9
> statement: long lines, code duplicate, no mock and well tests etc. -
> all these problems c
Hi Ronald,
I understand this, but I'm a bit confused about fate of lambdas with
such guideline since I see no more reasons to use them with p.9
statement: long lines, code duplicate, no mock and well tests etc. -
all these problems could be solved with assigning lambda to some name,
but now they a
On Thu, Aug 1, 2013 at 8:31 AM, Steven D'Aprano wrote:
> On 01/08/13 22:44, Nick Coghlan wrote:
>
> 4. Lines up to 99 characters are now permitted (but 79 is still the
>> preferred limit)
>>
>
> Coincidentally, there was a discussion about line length on python-list
> over the last couple of da
On 1 Aug, 2013, at 16:34, Alexander Shorin wrote:
> Hi Nick,
>
> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan wrote:
>> 9. Explicit guideline not to assign lambdas to names (use def, that's
>> what it's for)
>
> Even for propose to fit chars-per-line limit and/or to remove
> duplicates (espec
Hi Nick,
On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan wrote:
> 9. Explicit guideline not to assign lambdas to names (use def, that's
> what it's for)
Even for propose to fit chars-per-line limit and/or to remove
duplicates (especially for sorted groupby case)?
--
,,,^..^,,,
On 01/08/13 22:44, Nick Coghlan wrote:
4. Lines up to 99 characters are now permitted (but 79 is still the
preferred limit)
Coincidentally, there was a discussion about line length on python-list over
the last couple of days. I think the two most relevant comments are by Skip
Montanaro:
ht
On Thu, 01 Aug 2013 09:16:13 -0400, Fred Drake wrote:
> On Thu, Aug 1, 2013 at 9:10 AM, Antoine Pitrou wrote:
> > Something magic about 99?
>
> I'm guessing it's short enough you can say you tried, but long
> enough to annoy traditionalists anyway.
>
> I'm annoyed already. :-)
+1 :)
My termi
On 1 August 2013 23:10, Antoine Pitrou wrote:
> Le Thu, 1 Aug 2013 22:44:12 +1000,
> Nick Coghlan a écrit :
>> 4. Lines up to 99 characters are now permitted (but 79 is still the
>> preferred limit)
>
> Something magic about 99?
One less than 100, same as 79 is one less than 80. The "100" came f
On Thu, Aug 1, 2013 at 9:10 AM, Antoine Pitrou wrote:
> Something magic about 99?
I'm guessing it's short enough you can say you tried, but long
enough to annoy traditionalists anyway.
I'm annoyed already. :-)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Ein
Le Thu, 1 Aug 2013 22:44:12 +1000,
Nick Coghlan a écrit :
> 4. Lines up to 99 characters are now permitted (but 79 is still the
> preferred limit)
Something magic about 99?
cheers
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
With feedback from Guido, Barry, Raymond and others, I have updated
PEP 8 to better describe our current development practices. It started
as an update to describe the different between public and internal
interfaces and to advise against using wildcard imports, but became
substantially more :)
Fo
On 1 Aug, 2013, at 9:49, Christian Heimes wrote:
> Am 01.08.2013 09:03, schrieb Ronald Oussoren:
>>
>> On 31 Jul, 2013, at 23:50, christian.heimes
>> wrote:
>>
>>> http://hg.python.org/cpython/rev/0e09588a3bc2
>>> changeset: 84939:0e09588a3bc2
>>> parent: 84937:809a64ecd5f1
>>> parent
Am 01.08.2013 09:03, schrieb Ronald Oussoren:
>
> On 31 Jul, 2013, at 23:50, christian.heimes
> wrote:
>
>> http://hg.python.org/cpython/rev/0e09588a3bc2
>> changeset: 84939:0e09588a3bc2
>> parent: 84937:809a64ecd5f1
>> parent: 84938:83a55ca935f0
>> user:Christian Heimes
>>
On 31 Jul, 2013, at 23:50, christian.heimes wrote:
> http://hg.python.org/cpython/rev/0e09588a3bc2
> changeset: 84939:0e09588a3bc2
> parent: 84937:809a64ecd5f1
> parent: 84938:83a55ca935f0
> user:Christian Heimes
> date:Wed Jul 31 23:48:04 2013 +0200
> summary:
> Si
48 matches
Mail list logo
