On 23 July 2013 23:45, Victor Stinner victor.stin...@gmail.com 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 child processes. I don't
think that it is
On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren ronaldousso...@mac.comwrote:
On 23 Jul, 2013, at 17:36, Christian Heimes christ...@python.org wrote:
Am 23.07.2013 17:10, schrieb Benjamin Peterson:
PyErr_SetFromErrno() already and always returns NULL. Or do you prefer
to return NULL
On 24 Jul, 2013, at 8:43, Gregory P. Smith g...@krypto.org wrote:
On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren ronaldousso...@mac.com
wrote:
On 23 Jul, 2013, at 17:36, Christian Heimes christ...@python.org wrote:
Am 23.07.2013 17:10, schrieb Benjamin Peterson:
Le Wed, 24 Jul 2013 09:01:30 +0200,
Ronald Oussoren ronaldousso...@mac.com a écrit :
On 24 Jul, 2013, at 8:43, Gregory P. Smith g...@krypto.org wrote:
On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren
ronaldousso...@mac.com wrote:
On 23 Jul, 2013, at 17:36, Christian Heimes
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
On Wed, Jul 24, 2013 at 7:12 PM, Bohuslav Kabrda bkab...@redhat.com 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 Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda bkab...@redhat.com 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 24 July 2013 10:12, Bohuslav Kabrda bkab...@redhat.com 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
On Wed, Jul 24, 2013 at 12:36 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 24 July 2013 10:12, Bohuslav Kabrda bkab...@redhat.com 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
On Wed, Jul 24, 2013 at 5:12 AM, Bohuslav Kabrda bkab...@redhat.com 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
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda bkab...@redhat.com 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
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
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
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
On 25 July 2013 01:26, Toshio Kuratomi a.bad...@gmail.com 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
On 25 July 2013 01:41, Nick Coghlan ncogh...@gmail.com 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
On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda bkab...@redhat.com 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
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
On 07/24/2013 05:56 PM, Lennart Regebro wrote:
On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda bkab...@redhat.com wrote:
- Should we point /usr/bin/python to Python 3 when we make the move?
No.
To be more explicit. I
Am 24.07.13 17:56, schrieb Lennart Regebro: On Wed, Jul 24, 2013 at
3:54 PM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda
bkab...@redhat.com wrote:
- Should we point /usr/bin/python to Python 3 when we make the move?
No.
To be more explicit. I
On Thu, Jul 25, 2013 at 2:21 AM, Laurent Gautier lgaut...@gmail.com 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
On Wed, Jul 24, 2013 at 10:56 AM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda bkab...@redhat.com wrote:
- Should we point /usr/bin/python to Python 3 when we make the move?
On Jul 24, 2013, at 08:26 AM, Toshio Kuratomi wrote:
nod 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
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 Linux
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
On Wed, Jul 24, 2013 at 6:04 PM, Terry Reedy tjre...@udel.edu 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
On 07/24/2013 06:30 PM, Chris Angelico wrote:
On Thu, Jul 25, 2013 at 2:21 AM, Laurent Gautier lgaut...@gmail.com 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
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 *nix user, I
On Tue, Jul 23, 2013 at 4:21 PM, Richard Oudkerk shibt...@gmail.com 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
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 Wed, Jul 24, 2013 at 11:13 AM, Richard Oudkerk shibt...@gmail.com 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
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
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
* however, users
On Wed, Jul 24, 2013 at 7:22 PM, Laurent Gautier lgaut...@gmail.com 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
2013/7/24 Richard Oudkerk shibt...@gmail.com:
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
On Wed, 24 Jul 2013 10:56:05 -0700
Guido van Rossum gu...@python.org 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
On Wed, Jul 24, 2013 at 2:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 24 Jul 2013 10:56:05 -0700
Guido van Rossum gu...@python.org 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
On Wed, 24 Jul 2013 15:25:50 -0700
Guido van Rossum gu...@python.org 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
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
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 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 you call daemon?
On 25 Jul 2013 05:30, Toshio Kuratomi a.bad...@gmail.com 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
On 25Jul2013 00:35, Antoine Pitrou solip...@pitrou.net wrote:
| On Wed, 24 Jul 2013 15:25:50 -0700
| Guido van Rossum gu...@python.org 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
On Wed, Jul 24, 2013 at 3:35 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 24 Jul 2013 15:25:50 -0700
Guido van Rossum gu...@python.org 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
Guido van Rossum gu...@python.org 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
Ben Finney ben+pyt...@benfinney.id.au 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 URL:http://pypi.python.org/pypi/python-daemon/, and
development co-ordinated at Alioth
- Original Message -
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda bkab...@redhat.com 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
47 matches
Mail list logo
