- Original Message -
> Am 24.07.13 11:12, schrieb Bohuslav Kabrda:
> > - Should we point /usr/bin/python to Python 3 when we make the move?
>
> This should depend on the answer to this question:
> - for how long have you been providing /usr/bin/python2 binaries?
>
Huh, I don't know exact
- Original Message -
> On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
> > - Should we point /usr/bin/python to Python 3 when we make the move?
>
> No.
>
> > - What should user get after using "yum install python"?
>
> Will a base install include Python 3? If it does, I think y
Ben Finney writes:
> Work continues on the PEP 3143-compatible ‘python-daemon’, porting it to
> Python 3 and aiming for inclusion in the standard library.
At PyPI http://pypi.python.org/pypi/python-daemon/>, and
development co-ordinated at Alioth
https://alioth.debian.org/projects/python-daemon/
Guido van Rossum writes:
> To reduce the need for 3rd party subprocess creation code, we should
> have better daemon creation code in the stdlib -- I wrote some damn
> robust code for this purpose in my previous job, but it never saw the
> light of day.
Work continues on the PEP 3143-compatible
On Wed, Jul 24, 2013 at 3:35 PM, Antoine Pitrou wrote:
> On Wed, 24 Jul 2013 15:25:50 -0700
> Guido van Rossum wrote:
>> >> To reduce the need for 3rd party subprocess creation code, we should
>> >> have better daemon creation code in the stdlib -- I wrote some damn
>> >> robust code for this pur
On 25Jul2013 00:35, Antoine Pitrou wrote:
| On Wed, 24 Jul 2013 15:25:50 -0700
| Guido van Rossum wrote:
| > >> To reduce the need for 3rd party subprocess creation code, we should
| > >> have better daemon creation code in the stdlib -- I wrote some damn
| > >> robust code for this purpose in my
On 25 Jul 2013 05:30, "Toshio Kuratomi" wrote:
>
> On Wed, Jul 24, 2013 at 12:42:09PM -0400, Barry Warsaw wrote:
> > On Jul 25, 2013, at 01:41 AM, Nick Coghlan wrote:
> >
> > >How's this for an updated wording in the abstract:
> > >
> > > * for the time being, all distributions should ensure that
On 7/24/2013 6:25 PM, Guido van Rossum wrote:
>>> To reduce the need for 3rd party subprocess creation code, we should
>>> have better daemon creation code in the stdlib -- I wrote some damn
>>> robust code for this purpose in my previous job, but it never saw the
>>> light of day.
>>
>> What do yo
Chris Angelico wrote:
print "Hello, world!"
SyntaxError: invalid syntax
Is it safe
to presume that it's more likely a syntax error will come from an
interpreter version mismatch than a code bug?
Maybe look at sys.args[0], and if it ends in "python" with
no version number, add something to the
On 24/07/2013 10:50pm, Victor Stinner wrote:
So would it be possible to implement the pass_fds parameter of
subprocess using spawnl() or the undocumented fields?
Not in a non-racy way.
spawnv() calls CreateProcess() with bInheritHandles=TRUE, so *all*
inheritable handles are inherited by the
On Wed, 24 Jul 2013 15:25:50 -0700
Guido van Rossum wrote:
> >> To reduce the need for 3rd party subprocess creation code, we should
> >> have better daemon creation code in the stdlib -- I wrote some damn
> >> robust code for this purpose in my previous job, but it never saw the
> >> light of day
On Wed, Jul 24, 2013 at 2:57 PM, Antoine Pitrou wrote:
> On Wed, 24 Jul 2013 10:56:05 -0700
> Guido van Rossum wrote:
>>
>> But I'm also ready to propose that all this is such a mess that we
>> *should* change the default fd/handle inheritance to False, *across
>> platforms*, and damn the torpedo
On Wed, 24 Jul 2013 10:56:05 -0700
Guido van Rossum wrote:
>
> But I'm also ready to propose that all this is such a mess that we
> *should* change the default fd/handle inheritance to False, *across
> platforms*, and damn the torpedoes -- i.e. accept breaking all
> existing 3rd party UNIX code f
2013/7/24 Richard Oudkerk :
>> Wow. Indeed you can -- I just tested this myself. How is this
>> accomplished? I guess the CRT has a backchannel to talk to itself when
>> it creates a process using spawn*?
>
> CreateProcess() takes a STARTUPINFO argument with undocumented fields
> cbReserved2, lpRes
On Wed, Jul 24, 2013 at 7:22 PM, Laurent Gautier wrote:
> The wrapper in /usr/bin/python:
> - could use what is in 2to3. I think that most of the cases are solved
> there.
Only the most trivial cases are solved completely by 2to3, and the
error messages you would get would be hard to understand,
On Wed, Jul 24, 2013 at 12:42:09PM -0400, Barry Warsaw wrote:
> On Jul 25, 2013, at 01:41 AM, Nick Coghlan wrote:
>
> >How's this for an updated wording in the abstract:
> >
> > * for the time being, all distributions should ensure that python
> >refers to the same target as python2
> > * howeve
On 24/07/2013 7:17pm, Guido van Rossum wrote:
> Does it also inherit sockets (which take up a different namespace than
> regular FDs in CRT, unlike UNIX)?
Not reliably. Processes created with CreateProcess() seems to inherit
socket handles just like normal handles on my computer, but on some
o
On Wed, Jul 24, 2013 at 11:13 AM, Richard Oudkerk wrote:
>> Wow. Indeed you can -- I just tested this myself. How is this
>> accomplished? I guess the CRT has a backchannel to talk to itself when
>> it creates a process using spawn*?
>
> CreateProcess() takes a STARTUPINFO argument with undocument
> Wow. Indeed you can -- I just tested this myself. How is this
> accomplished? I guess the CRT has a backchannel to talk to itself when
> it creates a process using spawn*?
CreateProcess() takes a STARTUPINFO argument with undocumented fields
cbReserved2, lpReserved2. They are used to pass an
On Tue, Jul 23, 2013 at 4:21 PM, Richard Oudkerk wrote:
> On 23/07/2013 11:45pm, Victor Stinner wrote:
>>
>> Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on
>> *handles*, as indicated in its name. On Windows, file*descriptors*
>> are never inherited (are always closed) in chil
Gustavo Carneiro, 24.07.2013 19:16:
> On Wed, Jul 24, 2013 at 6:04 PM, Terry Reedy wrote:
>> On 7/24/2013 5:12 AM, Bohuslav Kabrda wrote:
>>> Hi all, in recent days, there has been a discussion on fedora-devel
>>> (see thread [1]) about moving to Python 3 as a default.
>>
>> Not being a current *ni
On 07/24/2013 06:30 PM, Chris Angelico wrote:
On Thu, Jul 25, 2013 at 2:21 AM, Laurent Gautier wrote:
- errors that are typical of "Python 2 script running with Python
3"-specific are probably limited (e.g., use of unicode, use of xrange,
etc...)
The most common, in interactive scripts at lea
On Wed, Jul 24, 2013 at 6:04 PM, Terry Reedy wrote:
> On 7/24/2013 5:12 AM, Bohuslav Kabrda wrote:
>
>> Hi all, in recent days, there has been a discussion on fedora-devel
>> (see thread [1]) about moving to Python 3 as a default.
>>
>
> Default-shift is a known natural language phenomenon.
> htt
On 7/24/2013 5:12 AM, Bohuslav Kabrda wrote:
Hi all, in recent days, there has been a discussion on fedora-devel
(see thread [1]) about moving to Python 3 as a default.
Default-shift is a known natural language phenomenon.
https://en.wikipedia.org/wiki/Retronym
It is inevitably messy in the mid
On Jul 25, 2013, at 01:41 AM, Nick Coghlan wrote:
>How's this for an updated wording in the abstract:
>
> * for the time being, all distributions should ensure that python
>refers to the same target as python2
> * however, users should be aware that python refers to python3 on at
>least Arch Lin
On Jul 24, 2013, at 08:26 AM, Toshio Kuratomi wrote:
> I think bkabrda is looking for some clarification on PEP-394. My
>reading and participation in the previous discussions lead me to believe
>that while PEP-394 wants to be diplomatic, the message it wants to get
>across is:
>
>1) warn distrib
On Wed, Jul 24, 2013 at 10:56 AM, Lennart Regebro wrote:
> On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro wrote:
>> On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
>>> - Should we point /usr/bin/python to Python 3 when we make the move?
>>
>> No.
>
> To be more explicit. I think it's
On Thu, Jul 25, 2013 at 2:21 AM, Laurent Gautier wrote:
> - errors that are typical of "Python 2 script running with Python
> 3"-specific are probably limited (e.g., use of unicode, use of xrange,
> etc...)
>
The most common, in interactive scripts at least, is likely to be:
>>> print "Hello, wo
Am 24.07.13 17:56, schrieb Lennart Regebro:> On Wed, Jul 24, 2013 at
3:54 PM, Lennart Regebro wrote:
>> On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda
wrote:
>>> - Should we point /usr/bin/python to Python 3 when we make the move?
>>
>> No.
>
> To be more explicit. I think it's perfectly fine
On 07/24/2013 05:56 PM, Lennart Regebro wrote:
On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro wrote:
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
- Should we point /usr/bin/python to Python 3 when we make the move?
No.
To be more explicit. I think it's perfectly fine to not pr
On Jul 24, 2013, at 05:12 AM, Bohuslav Kabrda wrote:
>in recent days, there has been a discussion on fedora-devel (see thread [1])
>about moving to Python 3 as a default.
I've been lurking via Gmane. :)
>- Should we point /usr/bin/python to Python 3 when we make the move?
Over in Debian (inheri
On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro wrote:
> On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
>> - Should we point /usr/bin/python to Python 3 when we make the move?
>
> No.
To be more explicit. I think it's perfectly fine to not provide a
/usr/bin/python at all, but I think
On 25 July 2013 01:41, Nick Coghlan wrote:
> How's this for an updated wording in the abstract:
>
> * for the time being, all distributions should ensure that python
> refers to the same target as python2
> * however, users should be aware that python refers to python3 on at
> least Arch Linux
On 25 July 2013 01:26, Toshio Kuratomi wrote:
> On Wed, Jul 24, 2013 at 09:34:11AM -0400, Brett Cannon wrote:
>> A similar discussion broke out when Arch Linux switched python to point to
>> python3. This led to http://www.python.org/dev/peps/pep-0394/ which says have
>> python2/python3, and have
Note: I'm the opposite number to bkabrda in the discussion on the Fedora
Lists about how quickly we should be breaking end-user expectations of what
"python" means.
On Wed, Jul 24, 2013 at 09:34:11AM -0400, Brett Cannon wrote:
>
>
>
> On Wed, Jul 24, 2013 at 5:12 AM, Bohuslav Kabrda wrote:
>
Am 24.07.13 11:12, schrieb Bohuslav Kabrda:
> - Should we point /usr/bin/python to Python 3 when we make the move?
This should depend on the answer to this question:
- for how long have you been providing /usr/bin/python2 binaries?
Users "should" have been explicit in declaring scripts as
/usr/bi
Haven't been over to yum land in a while, but usually they stabilize the
distro in synergy to the python version. Ubuntu came with 2.7, and I just
use sudo-apt get install, for 3.2(or a gui package manager), and then can
use 3.2 with using the command python3.2 in command line, or you can
compile f
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
> - Should we point /usr/bin/python to Python 3 when we make the move?
No.
> - What should user get after using "yum install python"?
Will a base install include Python 3? If it does, I think yum install
python should mean python3, and he
On Wed, Jul 24, 2013 at 5:12 AM, Bohuslav Kabrda wrote:
> Hi all,
> in recent days, there has been a discussion on fedora-devel (see thread
> [1]) about moving to Python 3 as a default.
> I'd really love to hear opinions on the matter from the upstream, mainly
> regarding these two points (that a
On Wed, Jul 24, 2013 at 12:36 PM, Paul Moore wrote:
> On 24 July 2013 10:12, Bohuslav Kabrda wrote:
>>
>> - What should user get after using "yum install python"?
>> There are basically few ways of coping with this:
>> 1) Just keep doing what we do, eventually far in the future drop "python"
>> p
On 24 July 2013 10:12, Bohuslav Kabrda wrote:
> - What should user get after using "yum install python"?
> There are basically few ways of coping with this:
> 1) Just keep doing what we do, eventually far in the future drop "python"
> package and never provide it again (= go on only with python3/
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
> - What should user get after using "yum install python"?
> There are basically few ways of coping with this:
> 1) Just keep doing what we do, eventually far in the future drop "python"
> package and never provide it again (= go on only wi
On Wed, Jul 24, 2013 at 7:12 PM, Bohuslav Kabrda wrote:
> - What should user get after using "yum install python"?
> There are basically few ways of coping with this:
> 1) Just keep doing what we do, eventually far in the future drop "python"
> package and never provide it again (= go on only wit
Hi all,
in recent days, there has been a discussion on fedora-devel (see thread [1])
about moving to Python 3 as a default.
I'd really love to hear opinions on the matter from the upstream, mainly
regarding these two points (that are not that clearly defined in my original
proposal and have been
Le Wed, 24 Jul 2013 09:01:30 +0200,
Ronald Oussoren a écrit :
>
> On 24 Jul, 2013, at 8:43, Gregory P. Smith wrote:
>
> >
> > On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren
> > wrote:
> >
> > On 23 Jul, 2013, at 17:36, Christian Heimes
> > wrote:
> >
> > > Am 23.07.2013 17:10, schrieb Be
On 24 Jul, 2013, at 8:43, Gregory P. Smith wrote:
>
> On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren
> wrote:
>
> On 23 Jul, 2013, at 17:36, Christian Heimes wrote:
>
> > Am 23.07.2013 17:10, schrieb Benjamin Peterson:
> >>> PyErr_SetFromErrno() already and always returns NULL. Or do you
46 matches
Mail list logo
