What is the status of the third party module on PyPI (distutils2)?
Does it contain all fixes done in the packaging module? Does it have
exactly the same API? Does it support Python 2.5 to 3.3, or maybe also
2.4?
How is the distutils2 module installed? Installed manually? Using pip
or setuptools? I
> It looks good to me! Also, I see no reason not to always use a 32bit
> version of the launcher other than
I'll change it, then - the strong reason *for* always using a 32-bit
launcher is packaging, as the 32-bit installer would otherwise have to
include both a 32-bit launcher and a 64-bit laun
On Wed, Jun 20, 2012 at 11:23 AM, Antoine Pitrou wrote:
> The question is what will happen after 3.3. There doesn't seem to be a
> lot of activity around the project, does it?
I think the desire is there, but there are enough "good enough"
approaches around that people find other more immediately
On Wed, Jun 20, 2012 at 1:51 PM, Yury Selivanov wrote:
> What if instead of 'optional', we have 'base_signature'
> (or 'from_signature')?
>
> sig = signature(func)
> params = OrderedDict(tuple(sig.parameters.items())[1:])
> new_sig = Signature(params, base_signature=sig)
>
> And for Param
On Wed, Jun 20, 2012 at 1:28 PM, Yury Selivanov wrote:
> On 2012-06-19, at 11:24 PM, Nick Coghlan wrote:
>> The constructor accepts an iterable of Parameter objects rather than a
>> mapping.
>
> That's the code I've ended up with:
>
> sig = signature(obj.__func__)
> return Signature
Nick nailed it (again).
On Tue, Jun 19, 2012 at 3:14 PM, Nick Coghlan wrote:
> Reverting and writing a full packaging PEP for 3.4 sounds like a wise
> course of action to me.
>
> Regards,
> Nick.
> --
> Sent from my phone, thus the relative brevity :)
>
>
Sorry, but I missed the announcement of an updated PEP.
It looks good to me! Also, I see no reason not to always use a 32bit
version of the launcher other than (a) the 64bit code already exists and
works and (b) it might mean it is no longer possible to do a complete
build of a 64bit Python w
On 2012-06-19, at 10:16 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>> If we even keep that at all for the initial version of the API, the
>>> direct "default" and "annotation" attributes would just be read-
On 2012-06-19, at 11:24 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 12:36 PM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
7. The idea of immutable Signature objects does highlight an annoyance
with
On Wed, Jun 20, 2012 at 12:36 PM, Yury Selivanov
wrote:
> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>> 7. The idea of immutable Signature objects does highlight an annoyance
>>> with the "attribute may be missing" style APIs. To actually du
Nick,
I started a new branch to experiment with immutable Signatures.
So far, almost everything works (except a couple unit-tests, that are
modifying now immutable Parameters & Signatures)
https://bitbucket.org/1st1/cpython/changesets/tip/branch(%22pep362-2%22)
I hope tomorrow we get some feedb
On 2012-06-19, at 10:16 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov
> wrote:
>>> 10. Similar to the discussion of convenience properties on Signature
>>> objects themselves, I now think we should drop the "args" and "kwargs"
>>
>> Big -1 on this one. Look at the c
On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>> 7. The idea of immutable Signature objects does highlight an annoyance
>> with the "attribute may be missing" style APIs. To actually duplicate
>> a signature correctly, including its return annotat
On Wed, Jun 20, 2012 at 12:15 PM, Yury Selivanov wrote:
> On 2012-06-19, at 10:06 PM, Nick Coghlan wrote:
>> True, the check for name clashes in Signature (and the implied numeric
>> "names") will cover the BoundArguments.parameters case
>
> Nick, I also would like to keep Parameter.name being req
On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov
wrote:
> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>> 6. I think "return_annotation" can safely be abbreviated to just
>> "annotation". The fact it is on the Signature object rather than an
>> individual parameter is enough to identify it as th
On 2012-06-19, at 10:06 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:29 AM, Yury Selivanov wrote:
>> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>>
>>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>>
2. The constructor for Parameter objects should require that names for
>>>
On Wed, Jun 20, 2012 at 11:29 AM, Yury Selivanov wrote:
> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>
>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>
>>> 2. The constructor for Parameter objects should require that names for
>>> positional-only parameters start with "<" and end with ">
On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>
>> 2. The constructor for Parameter objects should require that names for
>> positional-only parameters start with "<" and end with ">" to ensure
>> they can always be distinguished from standard p
On Tue, 19 Jun 2012 17:46:30 -0400
Éric Araujo wrote:
>
>I don’t think (a) would give us enough time; we really want a few
> months (and releases) to hash out the API (most notably with the pip and
> buildout developers) and clean the bdist situation. Likewise (c) would
> require develope
On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 3:53 AM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
>>> At some point it was suggested that Signature be put in provisionally so we
>>> could modify the API if needed -- are we doing that?
>>
On Wed, Jun 20, 2012 at 3:53 AM, Yury Selivanov wrote:
> On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
>> At some point it was suggested that Signature be put in provisionally so we
>> could modify the API if needed -- are we doing that?
>
> Well, it doesn't have much of an API right now (just f
On 2012-06-19, at 4:17 PM, Jim Jewett wrote:
>> I can tweak the PEP to make it more clear for those who don't know
>> that staticmethods are not exactly methods, but do we really need that?
>
> I would prefer it, if only because it surprised me. When do
> distinguish between methods, staticmethod
On 06/19/2012 05:46 PM, Éric Araujo wrote:
Hi all,
We need to make a decision about the packaging module in Python 3.3.
Please read this message and breathe deeply before replying :)
...
With beta coming, a way to deal with that unfortunate situation needs to
be found. We could (a) grant an
On 19 June 2012 22:46, Éric Araujo wrote:
[...]
> This leaves (d), after long reflection, as my preferred choice, even though
> I disliked the idea at first (and I fully expect Tarek to feel the same
> way).
I agree with Nick. It's regrettable, but this is probably the wisest
course of action. R
Éric Araujo wrote:
This leaves (d), after long reflection, as my preferred
choice, even though I disliked the idea at first (and I fully expect
Tarek to feel the same way).
Thanks for reading; please express your opinion (especially Tarek as
d2 project lead, Georg as RM and Guido as BDFL).
Reverting and writing a full packaging PEP for 3.4 sounds like a wise
course of action to me.
Regards,
Nick.
--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Hi all,
We need to make a decision about the packaging module in Python 3.3.
Please read this message and breathe deeply before replying :)
[Sorry this ends up being so long; Tarek, Georg, Guido, I hope you
have the time to read it.]
Let me first summarize the history of packaging
On Tue, Jun 19, 2012 at 2:10 PM, Yury Selivanov wrote:
> On 2012-06-19, at 12:33 PM, Jim Jewett wrote:
>
>> On Tue, Jun 19, 2012 at 11:53 AM, Yury Selivanov
>> wrote:
>>
Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
view pep-0362.txt @ 4466:659639095ace
===
On 2012-06-19, at 12:33 PM, Jim Jewett wrote:
> On Tue, Jun 19, 2012 at 11:53 AM, Yury Selivanov
> wrote:
>
>>> Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
>>> view pep-0362.txt @ 4466:659639095ace
>>> ==
>
>>> 142 * args : tuple
>>> 143 Tuple of positiona
On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
>>> Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.
Yury Selivanov wrote:
On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of
On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> Hello,
>> The new revision of PEP 362 has been posted:
>> http://www.python.org/dev/peps/pep-0362/
>> Summary:
>> 1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
>> __copy__ creates a shallow copy of Signa
Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of Signature, shallow copying its
Parameters as well.
2. 'Signature.fo
On Tue, Jun 19, 2012 at 11:53 AM, Yury Selivanov
wrote:
>> Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
>> view pep-0362.txt @ 4466:659639095ace
>> ==
>> 142 * args : tuple
>> 143 Tuple of positional arguments values. Dynamically computed from
>> 144
Jim,
On 2012-06-19, at 11:33 AM, Jim Jewett wrote:
> I've limited this to minor issues, but kept python-dev in the loop
> because some are questions, rather than merely editorial.
>
>
> Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
>
> view pep-0362.txt @ 4466:659639095ace
>
>
>
Jim Jewett wrote:
48 * parameters : OrderedDict
49 An ordered mapping of parameters' names to the corresponding
50 Parameter objects (keyword-only arguments are in the same order
51 as listed in ``code.co_varnames``).
Are you really sure you want to promise the keywor
I've limited this to minor issues, but kept python-dev in the loop
because some are questions, rather than merely editorial.
Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
view pep-0362.txt @ 4466:659639095ace
Committing the latest changes to PEP 362 on behalf of Yury Selivanov.
a
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of Signature, shallow copying its
Parameters as well.
2. 'Signature.format()' was removed. I
On Tue, Jun 19, 2012 at 1:30 AM, "Martin v. Löwis" wrote:
>> Agreed, I would expect the same. I would think taking out the word
>> "only" and then flipping newer and older in the sentence would correct
>> it.
>
> Will change.
>
>>> "On 64bit Windows with both 32bit and 64bit implementations of the
On 19.06.12 15:13, Antoine Pitrou wrote:
sys.stdin
<_io.TextIOWrapper name='' mode='r' encoding='UTF-8'>
So it's a TextIOWrapper from the _io module (which is really the
implementation of the io module). You'll find its source in
Modules/_io. TextIOWrapper objects are defined in Modules/_io/tex
Hi,
On Tue, 19 Jun 2012 04:39:30 -0700 (PDT)
gmspro wrote:
> Hi,
>
> I'm working on this bug to fix it. http://bugs.python.org/issue15068
I'm not sure why you think this is fixable, given the comments on the
tracker. What is your plan?
> >>> from sys import stdin
> >>> str=stdin.read()
> hell
It depends on the Python version. In 3.3, for example, look into
Modules/_io/fileio.c
Eli
On Tue, Jun 19, 2012 at 2:39 PM, gmspro wrote:
> Hi,
>
> I'm working on this bug to fix it. http://bugs.python.org/issue15068
>
> >>> from sys import stdin
> >>> str=stdin.read()
> hello
> hello world
>
Hi,
I'm working on this bug to fix it. http://bugs.python.org/issue15068
>>> from sys import stdin
>>> str=stdin.read()
hello
hello world
CTRL+D
CTRL+D
Can anyone tell me where is stdin.read() function defined?
Or where is sys.stdin defined?
Or which function is called for str=stdin.read() ?
Th
On Tue, 19 Jun 2012 01:41:44 +0200
brian.curtin wrote:
> http://hg.python.org/cpython/rev/8281233ec648
> changeset: 77514:8281233ec648
> user:Brian Curtin
> date:Mon Jun 18 18:41:07 2012 -0500
> summary:
> Fix #14772: Return the destination from some shutil functions.
>
> fi
On 06/18/2012 07:35 PM, Yury Selivanov wrote:
BTW, http://bugs.python.org/issue15008 has the latest implementation
attached (if anybody wants to play with it)
I've also posted the latest minor tweaks to the PEP, on behalf of Yury.
The new version is already live:
http://www.python.org/de
Hi Stefan,
On Tue, Jun 19, 2012 at 8:28 AM, Stefan Behnel wrote:
> Any reason you didn't write the C parts in Cython?
'''As a general rule, when there is a design issue to resolve, we pick
the solution that is the “most C-like”.''' (from the documentation).
But you are welcome to write Cython bi
Hi Greg,
On Tue, Jun 19, 2012 at 8:30 AM, Greg Ewing wrote:
> Is there any provision for keeping the compiled
> C code and distributing it along with an application?
> Requiring a C compiler to be present at all times
> could be a difficulty for Windows.
We are aware of it and doing that is work
47 matches
Mail list logo
