Antoine Pitrou writes:
> Le vendredi 03 décembre 2010 à 13:58 +0900, Stephen J. Turnbull a
> écrit :
> > Antoine Pitrou writes:
> >
> > > The legacy format argument looks like a red herring to me. When
> > > converting from a format to another it is the programmer's job to
> > > his/her
Alexander Belopolsky writes:
> In fact, once the language moratorium is over, I will argue that
> str.encode() and byte.decode() should deprecate encoding argument and
> just do UTF-8 encoding/decoding. Hopefully by that time most people
> will forget that other encodings exist. (I can dream
"Martin v. Löwis", 02.12.2010 21:24:
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.
Thanks! will do (I'll also take into consideration the propos
> Am I still missing something?
Apparently. The hole C API would break if objects would move in memory.
Since they have to stay at fixed addresses, it's easy enough to use the
address as ID. There is no problem to be solved here.
Regards,
Martin
___
Pyt
To build the trunk Python 3k, it seems that Python 2 has to be installed.
This is because Objects/typeslots.py is called in the Makefile, and this
file uses Python 2 "print statement" syntax, which fails if $(PYTHON) is
actually Python 3.
Can anyone reproduce this?
Eli
___
> I'm not really complaining (the API fixes are long overdue), just
> leaving a comment that what a compiler considers a warning or error
> pretty much depends on compiler, platform and configuration.
No no no. It does *not* depend on compiler, platform, or configuration.
It *only* depends on the
> I'm afraid I don't follow you. Unless you're suggesting some sort of
> esoteric object system whereby objects *don't* have identity (e.g. where
> objects are emergent properties of some sort of distributed,
> non-localised "information"), any object naturally has an identity --
> itself.
Not in
Am 04.12.2010 09:48, schrieb Eli Bendersky:
> To build the trunk Python 3k, it seems that Python 2 has to be installed.
> This is because Objects/typeslots.py is called in the Makefile, and this
> file uses Python 2 "print statement" syntax, which fails if $(PYTHON) is
> actually Python 3.
This sh
On Dec 4, 2010, at 11:13, "Martin v. Löwis" wrote:
> Am 04.12.2010 09:48, schrieb Eli Bendersky:
>> To build the trunk Python 3k, it seems that Python 2 has to be installed.
>> This is because Objects/typeslots.py is called in the Makefile, and this
>> file uses Python 2 "print statement" syn
Martin v. Löwis wrote:
I'm afraid I don't follow you. Unless you're suggesting some sort of
esoteric object system whereby objects *don't* have identity (e.g. where
objects are emergent properties of some sort of distributed,
non-localised "information"), any object naturally has an identity --
i
Le samedi 04 décembre 2010 à 17:13 +0900, Stephen J. Turnbull a écrit :
> Antoine Pitrou writes:
> > Le vendredi 03 décembre 2010 à 13:58 +0900, Stephen J. Turnbull a
> > écrit :
> > > Antoine Pitrou writes:
> > >
> > > > The legacy format argument looks like a red herring to me. When
> > >
On Fri, 3 Dec 2010 18:11:57 -0500
James Y Knight wrote:
> On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote:
>
> > Am 03.12.2010 23:48, schrieb Éric Araujo:
> >>> But I'm not interested at all in having it in distutils2. I want the
> >>> Python build itself to use it, and alas, I can't because o
On Sat, 4 Dec 2010 15:06:45 +1100
Cameron Simpson wrote:
> On 03Dec2010 18:15, James Y Knight wrote:
> | On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote:
> | > gc is implementation specific. CPython uses ref counting + cycle
> | > gc. A constraint on all implementations is that objects have a fixed
On Sat, 4 Dec 2010 11:20:57 +0200
Eli Bendersky wrote:
>
> I had the error pop out in a real build, so the time stamp is probably not a
> 100% guarantee. Therefore I think it's good that you made it version
> agnostic. This should be probably be a requirement for all scripts that are
> part of
On Sat, 4 Dec 2010 10:10:44 +0100 (CET)
gregory.p.smith wrote:
> Author: gregory.p.smith
> Date: Sat Dec 4 10:10:44 2010
> New Revision: 87010
>
> Log:
> issue7213 + issue2320: Cause a DeprecationWarning if the close_fds argument is
> not passed to subprocess.Popen as the default value will be
> Surely even in Java or C#, objects have an *identity* even if the
> language doesn't provide a way to query their distinct *identification*.
When people said "the id of an object should this or that", they always
meant identification, not identity (perhaps except for you). Nobody
would propose t
Steven D'Aprano writes:
> Martin v. Löwis wrote:
> >> It seems counter-productive to me to bother with an identity function
> >> which doesn't meet that constraint. If id(x) == id(y) implies nothing
> >> about x and y (they may, or may not, be the same object) then what's the
> >> point?
> >
On Sat, Dec 4, 2010 at 1:37 PM, Antoine Pitrou wrote:
> On Sat, 4 Dec 2010 15:06:45 +1100
> Cameron Simpson wrote:
>> On 03Dec2010 18:15, James Y Knight wrote:
>> | On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote:
>> | > gc is implementation specific. CPython uses ref counting + cycle
>> | > gc. A
On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:
> Er, normally you don't need *any* Python installed to build Python (be
> it 3.x or 2.x).
Are you sure about this? I remember needing an existing Python to
building Python 2.7 on a new python-less install of FreeBSD a couple
of months ago.
Le samedi 04 décembre 2010 à 13:23 +, Mark Dickinson a écrit :
> On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:
> > Er, normally you don't need *any* Python installed to build Python (be
> > it 3.x or 2.x).
>
> Are you sure about this? I remember needing an existing Python to
> build
On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote:
> On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:
>> Er, normally you don't need *any* Python installed to build Python (be
>> it 3.x or 2.x).
>
> Are you sure about this? I remember needing an existing Python to
> building Python 2.7
2010/12/4 Mark Dickinson :
> On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote:
>> On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:
>>> Er, normally you don't need *any* Python installed to build Python (be
>>> it 3.x or 2.x).
>>
>> Are you sure about this? I remember needing an existin
Le samedi 04 décembre 2010 à 13:39 +, Mark Dickinson a écrit :
> On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote:
> > On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:
> >> Er, normally you don't need *any* Python installed to build Python (be
> >> it 3.x or 2.x).
> >
> > Are you su
On Sat, Dec 4, 2010 at 1:40 PM, Benjamin Peterson wrote:
> You have to touch Include/Python-ast.h and Python/Python-ast.c. We do
> this for release tarballs.
Ah, that makes sense. Thanks.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On Sat, Dec 4, 2010 at 15:41, Antoine Pitrou wrote:
> Le samedi 04 décembre 2010 à 13:39 +, Mark Dickinson a écrit :
> > On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson
> wrote:
> > > On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou
> wrote:
> > >> Er, normally you don't need *any* Python ins
Quotes are out of order.
"Martin v. Löwis" writes:
> No, it's not. java.lang.Object.hashCode() is equivalent to Python's
> hash(). In particular, for both of these, the following requirement
> holds: object that *compare* equal must hash equal.
Aha. I see, now. That is indeed a different co
On Fri, Dec 03, 2010 at 11:52:41PM +0100, "Martin v. Löwis" wrote:
> Am 03.12.2010 23:48, schrieb Éric Araujo:
> >> But I'm not interested at all in having it in distutils2. I want the
> >> Python build itself to use it, and alas, I can't because of the freeze.
> > You can’t in 3.2, true. Neither
On Sat, Dec 4, 2010 at 12:27 PM, Antoine Pitrou wrote:
> On Fri, 3 Dec 2010 18:11:57 -0500
> James Y Knight wrote:
>
>> On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote:
>>
>> > Am 03.12.2010 23:48, schrieb Éric Araujo:
>> >>> But I'm not interested at all in having it in distutils2. I want the
Le 04/12/2010 17:55, Tarek Ziadé a écrit :
> On Sat, Dec 4, 2010 at 12:27 PM, Antoine Pitrou wrote:
>>> It seems like it'd be a good idea to start integrating distutils2 into
>>> python trunk immediately after the 3.2 branch is cut, then.
>>
>> +1 from me.
>
> +1 too.
+1, and I take responsibil
On Sat, Dec 4, 2010 at 3:45 AM, Antoine Pitrou wrote:
> On Sat, 4 Dec 2010 10:10:44 +0100 (CET)
> gregory.p.smith wrote:
> > Author: gregory.p.smith
> > Date: Sat Dec 4 10:10:44 2010
> > New Revision: 87010
> >
> > Log:
> > issue7213 + issue2320: Cause a DeprecationWarning if the close_fds
> a
On 4 December 2010 18:14, Gregory P. Smith wrote:
>
>
> On Sat, Dec 4, 2010 at 3:45 AM, Antoine Pitrou wrote:
>>
>> On Sat, 4 Dec 2010 10:10:44 +0100 (CET)
>> gregory.p.smith wrote:
>> > Author: gregory.p.smith
>> > Date: Sat Dec 4 10:10:44 2010
>> > New Revision: 87010
>> >
>> > Log:
>> > iss
> Why is useful to expose an identity hash? AFAICS it is *only* useful
> in building an identity hash table. If so, why not just provide id()
> or the is operator or both and be done with it?
That's precisely James' point: Java provides the identity hash
*instead* of the id() function (i.e. it d
> At the language summit it was proposed and seemed generally accepted (maybe
> I took silence as consent... it's been almost a year now) that bold new
> modules (and bold rewrites of existing modules since it fell out of the
> distutils/2 discussion) should get implemented in a module on pypi befo
> 1. Parts of the Makefile that use Python checked if Python is installed
> and generate a useful error if not.
> 2. All Python scripts that are part of the build should be 2-vs-3
> version agnostic for the time being (= until Python 2 is distant
> history, which won't happen soon)
I think this is
On Sat, Dec 4, 2010 at 11:28 AM, Paul Moore wrote:
> On 4 December 2010 18:14, Gregory P. Smith wrote:
> >
> >
> > On Sat, Dec 4, 2010 at 3:45 AM, Antoine Pitrou
> wrote:
> >>
> >> On Sat, 4 Dec 2010 10:10:44 +0100 (CET)
> >> gregory.p.smith wrote:
> >> > Author: gregory.p.smith
> >> > Date:
On Fri, Dec 3, 2010 at 12:10 AM, Alexander Belopolsky
wrote:
..
> I don't think decimal module should support non-European decimal
> digits. The only place where it can make some sense is in int()
> because here we have a fighting chance of producing a reasonable
> definition. The motivating us
DeprecationWarnings that show up in a lot of existing code are controversial
and have caused pain in the past. I'd like to leave this on for 3.2 beta1 and
see how things go. We can remove the warning if it is deemed too noisy during
any betas. (case study: the md5 and sha module DeprecationWa
> I actually wonder if Python's re module can claim to provide even
> Basic Unicode Support.
Do you really wonder? Most definitely it does not.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
On 4 December 2010 20:13, Gregory P. Smith wrote:
>> This sounds like omitting the close_fds parameter is now considered
>> ill-advised, if not outright wrong.
[...]
> Making the change was intended to force the discussion. I'm glad that
> worked. :)
:-)
> I don't like the thought of requiring
On 04/12/2010 11:27, Antoine Pitrou wrote:
On Fri, 3 Dec 2010 18:11:57 -0500
James Y Knight wrote:
On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it,
On 4 December 2010 22:51, Terry Reedy wrote:
> My feeling is that we should be able to correct bad-enough mistakes.
That's fair. Is this a "bad-enough mistake"? From a brief reading of
the 2 bug reports, combined with my own trouble-free experience with
Popen (always leaving close_fds as default)
On 4 December 2010 23:07, Paul Moore wrote:
> Is there an issue on Windows? If not, and given how different FD
> inheritance is on Windows, I'd argue that in the absence of bug
> reports, there's no need to change behaviour on Windows.
Actually, from the error message I just got:
ValueError: clo
On 12/4/2010 3:07 PM, Paul Moore wrote:
The original goal was for subprocess to replace os.system, os.popen,
os.spawn, etc. That's never quite happened because subprocess is just
a little bit too conceptually complex for those basic tasks.
Is that way? I didn't find it particularly hard to lea
On Sat, Dec 4, 2010 at 20:04, hirokazu.yamamoto
wrote:
> Author: hirokazu.yamamoto
> Date: Sun Dec 5 03:04:16 2010
> New Revision: 87070
>
> Log:
> Now can reproduce the error on AMD64 Windows Server 2008
> even where os.symlink is not supported.
>
>
> Modified:
> python/branches/py3k/Lib/test/
On 2010/12/05 11:08, Brian Curtin wrote:
I created #10540 for this issue, but the patch I have on there is just a bad
hack. I need to fix os.path.samefile for hard links, which might be easier
if we keep st_ino data in stat structures on Windows.
MSDN says,
http://msdn.microsoft.com/en-us/libra
I missed it, st_dev is not set yet. When I set st_dev with
dwVolumeSerialNumber, it was sometimes negative. Is it OK?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
46 matches
Mail list logo
