On Wed, 29 May 2013 08:08:14 +0200
Antoine Pitrou wrote:
> On Wed, 29 May 2013 12:40:32 +1000
> Nick Coghlan wrote:
> > On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen wrote:
> > > In article ,
> > > Łukasz Langa wrote:
> > >
> > >> Hello,
> > >> Since the initial version, several minor chang
On Wed, 29 May 2013 12:40:32 +1000
Nick Coghlan wrote:
> On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen wrote:
> > In article ,
> > Łukasz Langa wrote:
> >
> >> Hello,
> >> Since the initial version, several minor changes have been made to the
> >> PEP. The history is visible on hg.python.org
On Wed, May 29, 2013 at 10:14 AM, Brett Cannon wrote:
>> (FWIW, I think "ModuleManager" is a rather bad name :-)
>
> I'm open to suggestions, but the thing does manage the module so it at
> least makes sense.
I suggest ModuleInitialiser as the CM name, with a helper function to
make usage read be
On Wed, May 29, 2013 at 5:23 AM, Toshio Kuratomi wrote:
> On Tue, May 28, 2013 at 01:22:01PM -0400, Barry Warsaw wrote:
>> On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>>
>> >- If upstream doesn't deal with it, then we use a "python3-" prefix. This
>> >matches with our package naming
On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen wrote:
> In article ,
> Łukasz Langa wrote:
>
>> Hello,
>> Since the initial version, several minor changes have been made to the
>> PEP. The history is visible on hg.python.org. The most important
>> change in this version is that I introduced AB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/28/2013 05:52 PM, R. David Murray wrote:
> On Tue, 28 May 2013 12:17:49 -0400, Tres Seaver
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 05/28/2013 11:41 AM, R. David Murray wrote:
>>> I have the same complaint about setupt
On Wed, May 29, 2013 at 2:47 AM, "Martin v. Löwis" wrote:
> Am 28.05.13 18:20, schrieb Antoine Pitrou:
>> Le Tue, 28 May 2013 23:07:37 +1000,
>> Nick Coghlan a écrit :
>>> It was deliberate - a big part of PEP 432 is making sure that all the
>>> interpreter state lives *in* the interpreter state
On 29/05/13 07:27, PJ Eby wrote:
On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen wrote:
Is it true that this cannot be used for instance and class methods? It
dispatches based on the first argument, which is "self" for instance
methods, whereas the second argument would almost certainly be the
On 5/28/2013 7:42 PM, MRAB wrote:
"A_Guide_to_Idle_Tests", or
"An_Idle_Test_HOWTO".
[snip]
I'm somehow not happy about "_README", what with a single underscore
indicating "internal" in Python code.
The file is internal to the subset of IDLE developers writing tests, but...
Perhaps it wou
On Tue, May 28, 2013 at 5:40 PM, Antoine Pitrou wrote:
> On Tue, 28 May 2013 23:29:46 +0200 (CEST)
> brett.cannon wrote:
>>
>> +.. class:: ModuleManager(name)
>> +
>> +A :term:`context manager` which provides the module to load. The module
>> will
>> +either come from :attr:`sys.modules`
On 29/05/2013 00:29, Terry Jan Reedy wrote:
On 5/28/2013 3:39 PM, Antoine Pitrou wrote:
On Tue, 28 May 2013 15:06:39 -0400
Terry Reedy wrote:
Yes, Nick suggested README instead of what I had. I want a prefix to
keep it near the top of a directory listing even when other non
'test_xxx' files
On 5/28/2013 3:39 PM, Antoine Pitrou wrote:
On Tue, 28 May 2013 15:06:39 -0400
Terry Reedy wrote:
Yes, Nick suggested README instead of what I had. I want a prefix to
keep it near the top of a directory listing even when other non
'test_xxx' files are added. I thing '_' wold be better though.
On Tue, 28 May 2013 12:17:49 -0400, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/28/2013 11:41 AM, R. David Murray wrote:
> > I have the same complaint about setuptools entry-point scripts, where
> > I still haven't figured out how to go from what is in the file
On Tue, 28 May 2013 23:29:46 +0200 (CEST)
brett.cannon wrote:
>
> +.. class:: ModuleManager(name)
> +
> +A :term:`context manager` which provides the module to load. The module
> will
> +either come from :attr:`sys.modules` in the case of reloading or a fresh
> +module if loading a
On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen wrote:
> Is it true that this cannot be used for instance and class methods? It
> dispatches based on the first argument, which is "self" for instance
> methods, whereas the second argument would almost certainly be the
> argument one would want to
A question about the example:
how hard would it be to modify the example
@fun.register(list)
...
to work with other collections? If it is easy, I think it would make a
for a much more useful example.
-- Russell
___
Python-Dev mailing list
Python-Dev@
In article ,
Åukasz Langa wrote:
> Hello,
> Since the initial version, several minor changes have been made to the
> PEP. The history is visible on hg.python.org. The most important
> change in this version is that I introduced ABC support and completed
> a reference implementation.
>
> No ope
On Tue, 28 May 2013 15:06:39 -0400
Terry Reedy wrote:
> On 5/28/2013 2:14 AM, Benjamin Peterson wrote:
> > 2013/5/27 terry.reedy :
> >> http://hg.python.org/cpython/rev/c5d4c041ab47
> >> changeset: 83942:c5d4c041ab47
> >> parent: 83940:2ea849fde22b
> >> parent: 83941:24c3e7e08168
> >>
On Tue, 28 May 2013 12:21:25 -0700
"Russell E. Owen" wrote:
> Pep 422 proposes the following order for dealing with cyclic isolates:
>
>1. Weakrefs to CI objects are cleared, and their callbacks called. At
> this point, the objects are still safe to use.
>2. The finalizers of all CI obje
On Tue, May 28, 2013 at 01:22:01PM -0400, Barry Warsaw wrote:
> On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>
> >- If upstream doesn't deal with it, then we use a "python3-" prefix. This
> >matches with our package naming so it seemed to make sense. (But
> >Barry's point about l
Pep 422 proposes the following order for dealing with cyclic isolates:
1. Weakrefs to CI objects are cleared, and their callbacks called. At
this point, the objects are still safe to use.
2. The finalizers of all CI objects are called.
3. The CI is traversed again to determine if it is s
On 29/05/13 04:00, Antoine Pitrou wrote:
On Tue, 28 May 2013 16:02:00 +0300
Serhiy Storchaka wrote:
20.05.13 18:46, Antoine Pitrou написав(ла):
I think it is a legitimate case where to silence the original
exception. However, the binascii.Error would be more informative if it
said *which* non-
On Tue, May 28, 2013 at 2:04 PM, Barry Warsaw wrote:
> On May 28, 2013, at 01:57 PM, Daniel Holth wrote:
>
>>Wheel has no mechanism for renaming scripts (or any file) based on the
>>Python version used to install. Instead you would have to build
>>python-version-specific packages for each desired
On May 28, 2013, at 01:57 PM, Daniel Holth wrote:
>Wheel has no mechanism for renaming scripts (or any file) based on the
>Python version used to install. Instead you would have to build
>python-version-specific packages for each desired script name.
Note that I'm not trying to borrow any impleme
On Tue, 28 May 2013 16:02:00 +0300
Serhiy Storchaka wrote:
> 20.05.13 18:46, Antoine Pitrou написав(ла):
> > I think it is a legitimate case where to silence the original
> > exception. However, the binascii.Error would be more informative if it
> > said *which* non-base32 digit was encountered.
>
On Tue, 28 May 2013 13:27:18 -0400
Barry Warsaw wrote:
> On May 25, 2013, at 09:53 AM, Antoine Pitrou wrote:
>
> >How about always running the version specific targets, e.g.
> >nosetests-2.7?
>
> We have nosetests-2.7 and nosetests3 in /usr/bin, but we generally recommend
> folks not use these,
On Tue, May 28, 2013 at 1:30 PM, Barry Warsaw wrote:
> On May 25, 2013, at 03:12 AM, Chris McDonough wrote:
>
>>You probably already know this, but I'll mention it anyway. This
>>probably matters a lot for nose and pyflakes, but I'd say that for tox
>>it should not, it basically just scripts exec
On May 25, 2013, at 03:12 AM, Chris McDonough wrote:
>You probably already know this, but I'll mention it anyway. This
>probably matters a lot for nose and pyflakes, but I'd say that for tox
>it should not, it basically just scripts execution of shell commands.
>I'd think maybe in cases like tox
On May 25, 2013, at 09:53 AM, Antoine Pitrou wrote:
>How about always running the version specific targets, e.g.
>nosetests-2.7?
We have nosetests-2.7 and nosetests3 in /usr/bin, but we generally recommend
folks not use these, especially for things like (build time) package tests.
It's harder to
On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>Fedora is a bit of a mess... we try to work with upstream's intent when
>upstream has realized this problem exists and have a single standard when
>upstream does not. The full guidelines are here:
>
>http://fedoraproject.org/wiki/Packaging:Pyt
Am 28.05.13 18:20, schrieb Antoine Pitrou:
> Le Tue, 28 May 2013 23:07:37 +1000,
> Nick Coghlan a écrit :
>> It was deliberate - a big part of PEP 432 is making sure that all the
>> interpreter state lives *in* the interpreter state (as part of the
>> config struct).
>
> It sounds a bit exagerat
Am 28.05.13 15:07, schrieb Nick Coghlan:
>> Sounds fine (I don't like "Apps" much, but hey :-)).
>
> Unfortunately, I don't know any other short word for "things with main
> functions that we ship to end users" :)
Bike-sheddingly: POSIX calls them "commands and utilities":
https://www2.opengroup
Le Tue, 28 May 2013 23:07:37 +1000,
Nick Coghlan a écrit :
>
> It was deliberate - a big part of PEP 432 is making sure that all the
> interpreter state lives *in* the interpreter state (as part of the
> config struct). Splitting the two into separate compilation modules
> makes it possible to en
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/28/2013 11:41 AM, R. David Murray wrote:
> I have the same complaint about setuptools entry-point scripts, where
> I still haven't figured out how to go from what is in the file to the
> code that actually gets called.
Hmm, just dump the 'entr
On 5/28/2013 6:02 AM, Serhiy Storchaka wrote:
20.05.13 18:46, Antoine Pitrou написав(ла):
I think it is a legitimate case where to silence the original
exception. However, the binascii.Error would be more informative if it
said *which* non-base32 digit was encountered.
Please open a new issue
On May 25, 2013, at 06:17 AM, Chris McDonough wrote:
>I'm curious if folks have other concrete examples of global bindir
>executables other than nosetests and pydoc that need to be disambiguated
>by Python version. I'd hate to see it become standard practice to
>append "3" to scripts generated by
On May 25, 2013, at 05:57 PM, Nick Coghlan wrote:
>It seems to me the existing recommendation to use ``#!/usr/bin/env
>python`` instead of referencing a particular binary already covers the
>general case. The challenge for the distros is that we want a solution
>that *ignores* user level virtual e
On Tue, 28 May 2013 11:35:00 -0400, Barry Warsaw wrote:
> On May 24, 2013, at 04:23 PM, R. David Murray wrote:
>
> >Gentoo has a (fairly complex) driver script that is symlinked to all
> >of these bin scripts. The system then has the concept of the
> >"current python", which can be set to python
On May 24, 2013, at 04:23 PM, R. David Murray wrote:
>Gentoo has a (fairly complex) driver script that is symlinked to all
>of these bin scripts. The system then has the concept of the
>"current python", which can be set to python2 or python3. The default
>bin then calls the current default inte
On May 26, 2013, at 08:34 PM, Nick Coghlan wrote:
>As far as I am aware, there's nothing to clarify: new code should use
>underscores as word separators, code added to an existing module or
>based on existing API should follow the conventions of that module or
>API. This is what PEP 8 already says
On Wed, May 29, 2013 at 12:03 AM, Serhiy Storchaka wrote:
> 28.05.13 16:07, Nick Coghlan написав(ла):
>>
>> On Tue, May 28, 2013 at 10:31 PM, Antoine Pitrou
>> wrote:
>>>
>>> Le Tue, 28 May 2013 22:15:25 +1000,
>>> Nick Coghlan a écrit :
* moved the main executable source file from Mod
28.05.13 16:07, Nick Coghlan написав(ла):
On Tue, May 28, 2013 at 10:31 PM, Antoine Pitrou wrote:
Le Tue, 28 May 2013 22:15:25 +1000,
Nick Coghlan a écrit :
* moved the main executable source file from Modules to a separate
Apps directory
Sounds fine (I don't like "Apps" much, but hey :-)).
2013/5/28 Nick Coghlan :
> On Tue, May 28, 2013 at 10:31 PM, Antoine Pitrou wrote:
>> Le Tue, 28 May 2013 22:15:25 +1000,
>> Nick Coghlan a écrit :
>>> I have a feature branch where I'm intermittently working on the
>>> bootstrapping changes described in PEP 432.
>>>
>>> As part of those changes,
On Tue, May 28, 2013 at 9:07 AM, Nick Coghlan wrote:
> Unfortunately, I don't know any other short word for "things with main
> functions that we ship to end users" :)
We used to call such things "programs", but that term may no longer be
in popular parlance. :-) Or is it just too long?
-Fr
As part of those changes, I've cleaned up a few aspects of the repo
layout:
* moved the main executable source file from Modules to a separate
Apps directory
Do you mean things that go into the shared library
(libpythonXX/pythonXX.dll) vs executables?
___
20.05.13 18:46, Antoine Pitrou написав(ла):
I think it is a legitimate case where to silence the original
exception. However, the binascii.Error would be more informative if it
said *which* non-base32 digit was encountered.
Please open a new issue for this request (note that no other binascii o
On Tue, May 28, 2013 at 10:31 PM, Antoine Pitrou wrote:
> Le Tue, 28 May 2013 22:15:25 +1000,
> Nick Coghlan a écrit :
>> I have a feature branch where I'm intermittently working on the
>> bootstrapping changes described in PEP 432.
>>
>> As part of those changes, I've cleaned up a few aspects of
Le Tue, 28 May 2013 22:15:25 +1000,
Nick Coghlan a écrit :
> I have a feature branch where I'm intermittently working on the
> bootstrapping changes described in PEP 432.
>
> As part of those changes, I've cleaned up a few aspects of the repo
> layout:
>
> * moved the main executable source file
On May 28, 2013, at 10:15 PM, Nick Coghlan wrote:
>Would anyone object if I went ahead and posted patches for making
>these changes to the main repo?
When you say "post[ed] patches", do you mean you want to put them some place
for us to review? If so, sure, go ahead of course.
-Barry
__
I have a feature branch where I'm intermittently working on the
bootstrapping changes described in PEP 432.
As part of those changes, I've cleaned up a few aspects of the repo layout:
* moved the main executable source file from Modules to a separate
Apps directory
* moved the _freezeimportlib an
50 matches
Mail list logo
