> I think it would be great if Python were the first real adopter of this
> convention...
A convention without any adopters? Seems like a non sequitur...
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-
> Is there a reliable way to identify 32-bits and 64-bits Windows from
> within Python?
Not that I'm aware of. 'sys.platform=="win32" and "64 bits" in sys.version'
will be reliable when it returns True, but it might be wrong when it returns
False (although when it returns False, things will loo
This whole movement to condemn super because it's not "pure" strikes
me as wasted energy. That's my last word.
On Thu, May 1, 2008 at 8:28 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
>
> > On Thu, May 1, 2008 at 11:20 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >
>
I stand corrected on a few points. You've convinced me that ~/lib/ is
wrong. But I still don't like ~/.local/; not in the last place because
it's not any more local than any other dot files or directories. The
"symmetry" with /usr/local/ is pretty weak, and certainly won't help
beginning users.
As
Guido van Rossum schrieb:
On Thu, May 1, 2008 at 11:20 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
But the other two magical things about super() really bother me too. I
haven't looked at the new super in detail so far (and I don't know how
many others have), and two things are really strikin
On Thu, May 1, 2008 at 9:31 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> I just closed the release blocker I created (the
> backwards-compatibility issue with warnings.showwarning() ). I would
> like to add a PendingDeprecationWarning (or stronger) to 2.6 for
> showwarning() implementations
On Thu, May 1, 2008 at 1:26 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This is a reminder that the LAST planned alpha releases of Python 2.6 and
> 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over
> the next week so
On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote:
> On 11:45 pm, [EMAIL PROTECTED] wrote:
>
> > I like this, except one issue: I really don't like the .local
> > directory. I don't see any compelling reason why this needs to be
> > ~/.local/lib/ -- IMO it should just be ~/lib/. There's no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 1, 2008, at 7:45 PM, Guido van Rossum wrote:
On Thu, May 1, 2008 at 2:27 PM, Christian Heimes <[EMAIL PROTECTED]>
wrote:
Barry Warsaw schrieb:
This is a reminder that the LAST planned alpha releases of Python
2.6
and 3.0 are scheduled f
On Thu, 1 May 2008, Neal Becker wrote:
> It would be really nice to see support for some other backends, such as Hg
> or bzr (which are both written in python), in addition to svn.
/me starts the clamour for git
--
Cheers,
Leif
___
Python-3000 mailing
On Thu, May 1, 2008 at 4:37 PM, Neal Becker <[EMAIL PROTECTED]> wrote:
> It would be really nice to see support for some other backends, such as Hg
> or bzr (which are both written in python), in addition to svn.
Once it's open source feel free to add those!
--
--Guido van Rossum (home page: ht
On Thu, May 1, 2008 at 2:27 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Barry Warsaw schrieb:
>
> > This is a reminder that the LAST planned alpha releases of Python 2.6
> > and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be
> > diligent over the next week so that none of you
It would be really nice to see support for some other backends, such as Hg
or bzr (which are both written in python), in addition to svn.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
On Thu, May 1, 2008 at 4:24 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> | On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> | > As I understood this,one needs a diff to comment on.
> |
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
| > As I understood this,one needs a diff to comment on.
| > I can imagine wanting, or wanting others, to be able to comment on a
file
| > or
On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> As I understood this,one needs a diff to comment on.
> I can imagine wanting, or wanting others, to be able to comment on a file
> or lines of files without making a fake diff (of the file versus itself or
> a blank file).
As I understood this,one needs a diff to comment on.
I can imagine wanting, or wanting others, to be able to comment on a file
or lines of files without making a fake diff (of the file versus itself or
a blank file). Then only one column would be needed.
I presume the current site is for trial p
Barry Warsaw schrieb:
> This is a reminder that the LAST planned alpha releases of Python 2.6
> and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be
> diligent over the next week so that none of your changes break Python.
> The stable buildbots look moderately okay, let's see what we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a reminder that the LAST planned alpha releases of Python 2.6
and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be
diligent over the next week so that none of your changes break
Python. The stable buildbots look moderately
On Thu, May 1, 2008 at 2:15 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Torsten, I agree. Let's just rename ugettext() to gettext() and have it
> return unicodes. That's the cleanest API we can do for Python.
I have a patch for something like this at issue 2512.
--
Cheers,
Benjamin Peters
> Sounds like you agree that we should just rename the u-variants and
> forget about deprecation, correct?
Exactly.
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
htt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 1, 2008, at 2:59 PM, Martin v. Löwis wrote:
Are we going to want to keep the "u" variants of the gettext APIs
around in 3.0? Also, the unicode parameters (for .install methods)
don't make much sense in 3.0.
I don't see how we could remove th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 30, 2008, at 2:41 PM, Torsten Bronger wrote:
Indeed. From today's perspective, I see no use case for getting
human text snippets in byte strings encoded with the same encoding
that just happened to be used in the .mo file, or with the
"prefe
> Are we going to want to keep the "u" variants of the gettext APIs
> around in 3.0? Also, the unicode parameters (for .install methods)
> don't make much sense in 3.0.
>
> I don't see how we could remove them in 3.0, but perhaps rename then
> to their non-"u" variants and deprecate?
I think the
2008/4/30, Nick Coghlan <[EMAIL PROTECTED]>:
> In the bug tracker, Alexander mentioned the possibility of removing
> __length__ and __getitem__ support from range() objects in py3k, and
> implementing only __length_hint__ instead (leaving range() as a bare-bones
> iterable). I'm starting to like
On Thu, May 1, 2008 at 7:41 AM, Collin Winter <[EMAIL PROTECTED]> wrote:
>
> On Mon, Apr 28, 2008 at 7:30 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Transition Plan
> > ===
> >
> > For modules to be removed
> > -
> >
> > For the removal of modul
On Thu, May 01, 2008 at 01:49:37PM -0400, Terry Reedy wrote:
> I think standard Python should somehow have two options: escape everything
> but ASCII (for unambuguity and old display systems) and escape nothing that
> is potentially printable (leaving partially capable systems to fare as they
>
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> > I think "standard repertoire based on Unicode" may be confusing the
issue.
| >
| > By "standard repertoire" I mean that all Pythons will show the same
| > characters the same way, while "based on Unicode" is in
> > The escaping that repr() does is *not* to achieve unambiguity,
> > but to achieve printability.
>
> Well, if that is the case, then I withdraw my comments pretty much
> entirely, and apologize for the noise. I think you've already
> specified what is needed to achieve printability correctly
"Martin v. Löwis" writes:
> The escaping that repr() does is *not* to achieve unambiguity,
> but to achieve printability.
Well, if that is the case, then I withdraw my comments pretty much
entirely, and apologize for the noise. I think you've already
specified what is needed to achieve printab
On Thu, May 1, 2008 at 1:06 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> atsuo ishimoto writes:
>
> > > And where does Atsuo fall?
> >
> > Sorry, I cannot understand word 'fall', perhaps a colloquial expression?
>
> In this case, it means "what is your opinion, compared to Stephen an
> I still like this proposal. I don't quite understand the competing (?)
> proposal by Stephen Turnbull; perhaps Stephen can compare and contrast
> the two proposals? And where does Atsuo fall?
IIUC, Stephen proposes to use some of the "security" algorithms for
display, without (yet) specifying wh
Some of you may have seen a video recorded in November 2006 where I
showed off Mondrian, a code review tool that I was developing for
Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped
that I could release Mondrian as open source, but it was not to be:
due to its popularity insi
> > I think "standard repertoire based on Unicode" may be confusing the issue.
>
> By "standard repertoire" I mean that all Pythons will show the same
> characters the same way, while "based on Unicode" is intended to mean
> looking at TR#36 and TR#39 in picking the repertoires.
I don't think ei
> The problem is that this doesn't display the representation of strings
> and identifier names in an unambiguous way. "AKMOT" could be
> all-ASCII, it could be all-Cyrillic, or it could be a mixture of
> ASCII, Cyrillic, and Greek.
I don't see this is a problem. Yes, it can happen, but no, it is
On Thu, May 1, 2008 at 2:34 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> This should be done with a new function, not added to print. Once you
> specify an encoding, you have to write to sys.stdout.buffer, which is
> the underlying binary stream; but you'd have to flush the
> TextIOWrapper
On Thu, May 01, 2008, Guido van Rossum wrote:
> On Thu, May 1, 2008 at 7:25 AM, Aahz <[EMAIL PROTECTED]> wrote:
>>
>> Actually, the primary application I'm thinking of is a CGI that displays
>> part of a directory listing (paged) for manual processing of individual
>> files.
>
> But wouldn't yo
On Thu, May 1, 2008 at 3:20 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I think Giovanni's point is an important one as well - with an iterator,
> you can pipeline your operations far more efficiently, since you don't have
> to wait for the whole directory listing before doing anything (e.g. if
On Thu, May 1, 2008 at 7:25 AM, Aahz <[EMAIL PROTECTED]> wrote:
> Actually, the primary application I'm thinking of is a CGI that displays
> part of a directory listing (paged) for manual processing of individual
> files.
But wouldn't you usually want the listing sorted, while os.listdir()
does
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> In the slow example given, only one of the returned items needs to be a
>>> long
>>
>> This is Py3k. They are all longs.
>
> Not inside the object they aren't
Right, inside, they are longs - but the *returned items* are all longs.
> One way to opt
On Mon, Apr 28, 2008 at 7:30 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> [bcc to stdlib-sig]
>
> After two false starts over the YEARS of trying to cleanup and
> reorganize the stdlib, creating a SIG to get this going, having Guido
> give the PEP the once-over over the past several days, and c
On Thu, May 1, 2008 at 10:41 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> One way to optimise this (since all we need to support here is counting
> rather than arbitrary arithmetic) would be for the longrange iterator to use
> some simple pure C fixed point arithmetic internally to keep track of
Martin v. Löwis wrote:
In the slow example given, only one of the returned items needs to be a
long
This is Py3k. They are all longs.
Not inside the object they aren't - I believe the optimised one uses C
longs internally, and converts to a Python long when it returns the
values, whereas 'l
On Thu, May 01, 2008, "Martin v. L?wis" wrote:
> Guido van Rossum wrote:
>>
>> There is one use case I can see for an iterator-version of
>> os.listdir() (to be named os.opendir()): when globbing a huge
>> directory looking for a certain pattern. Using os.listdir() you end up
>> needed enough memor
> In the slow example given, only one of the returned items needs to be a
> long
This is Py3k. They are all longs.
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http
Martin v. Löwis wrote:
These numbers aren't ridiculously large. I just tried
for i in range(2**31): pass
on my (32-bit) laptop: it took 736.8 seconds, or about 12 and a bit minutes.
(An aside: in contrast,
for i in range(2**31-1): pass
took only 131.1 seconds; looks like there's some potent
Martin v. Löwis wrote:
Guido van Rossum wrote:
There is one use case I can see for an iterator-version of
os.listdir() (to be named os.opendir()): when globbing a huge
directory looking for a certain pattern. Using os.listdir() you end up
needed enough memory to hold all of the names at once. Us
> These numbers aren't ridiculously large. I just tried
>
> for i in range(2**31): pass
>
> on my (32-bit) laptop: it took 736.8 seconds, or about 12 and a bit minutes.
> (An aside: in contrast,
>
> for i in range(2**31-1): pass
>
> took only 131.1 seconds; looks like there's some potential f
48 matches
Mail list logo
