2008/12/4 "Martin v. Löwis" <[EMAIL PROTECTED]>:
> Any objections?
The timing is right, go for it.
Paul
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/o
2008/9/8 wesley chun <[EMAIL PROTECTED]>:
> the goal is admirable, but unless there are paying sponsors that
> require this deadline be met, i'd suggest that we can push the
> releases until they're ready. the changes that 2.6 and 3.0 bring are
> too major to be released before they are ready for
2008/9/4 Jesus Cea <[EMAIL PROTECTED]>:
> PS: If you mistype the method name, you get an error. If you mistype the
> attribute assignment, the bug goes unnoticed.
I'm neutral over the threading change, but this is a good point to
consider in general as part of the "method vs property" question whe
2008/9/4 Brett Cannon <[EMAIL PROTECTED]>:
> On Wed, Sep 3, 2008 at 7:33 PM, <[EMAIL PROTECTED]> wrote:
> All but dbm.dumb require some pre-existing library to exist to compile
> against. So any platform that has the proper libraries installed will
> be able to use ndbm or gnu, but as for which pl
On 19/06/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On behalf of the Python development team and the Python community, I am
> happy to announce the first beta releases of Python 2.6 and Python 3.0.
Any ETA for Windows builds? The web pages s
On 28/05/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
I care, but I struggle to understand the implications and/or what
On 15/05/2008, Paul Moore <[EMAIL PROTECTED]> wrote:
> My apologies if I misunderstood your proposal - I have almost no
> Unicode experience, and that probably shows :-)
One point I forgot to clarify is that I'm fully aware that
print(arbitrary_string) may display garbage, if th
On 15/05/2008, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
> I would like to call it "improve", not break :)
Please can you help me understand the impact here. I am running
Windows XP (UK English - console code page 850, which is some variety
of Latin 1). Currently, printing non-latin1 characters gi
On 15/05/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Consider code that gets an encoding passed in as a
> variable e. It knows it has a bytes instance b. To encode b from bytes
> to str (unicode), it can use s = b.decode(e).
To encode, you use .decode? It's nice to know it's not just me wh
On 29/04/2008, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 5:10 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> ...
> > Perhaps sched/mutex could be dumped in the Demo directory? Or perhaps we
> > should just get rid of them entirely and see if anyone with a real use case
>
On 15/04/2008, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> | So it sounds like we're doomed if we do, and damned if we don't. Or do
> | I misunderstand you? Do you have a practical suggestion?
>
> You understood the same as me.
That's how
On 04/04/2008, Zaur Shibzoukhov <[EMAIL PROTECTED]> wrote:
> Certainly! It don't intent to replace this way of defining/modifining
> properties. First, it is an example of "with" statement application.
> Second, suggested approach allow to write your example in the
> following way:
>
> class C
On 01/04/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > What really bugs me about this state of affairs is that I consider the
> > python 2 dict.items() to be safe and free of surprises, but I no
> > longer feel the same way about it in 3; this is really about the fact
> > that when you
On 26/03/2008, Thomas Heller <[EMAIL PROTECTED]> wrote:
> What I would like to see is a way to disable certain tests on certain
> machines;
> maybe by setting environment variables?
Could this be done by something like the following (completely
untested no time at the moment) change to regrte
On 21/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote:
> I tend to make a repository and make a working copy for each patch in it.
> The history is saved in the repository so it's efficient.
OK, so just lots of copies, fair enough. Presumably just use bzr diff
to create patches? Much like Sub
On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Just to head this off, this is not a specific vote of confidence for
> Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas
> were willing to put the time and effort to get the mirror up and going
> while the Bazaar team w
On 18/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > This is something that I've been pondering over for a while now, but I
> > haven't been able to come to any strong conclusions. I'd appreciate
> > some comment, and possibly a bit of clarification in the documentation
> > for migrating
This is something that I've been pondering over for a while now, but I
haven't been able to come to any strong conclusions. I'd appreciate
some comment, and possibly a bit of clarification in the documentation
for migrating to 3.0.
I'm basically an end user of Python. I don't write libraries or
fr
On 15/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Thomas Wouters suggests some new syntax:
>
> http://bugs.python.org/issue2292
[...]
> What do people think?
I like it. It's on the border of being too obscure (the examples are
logical, but I need to think to apply the logic - if you s
On 05/03/2008, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> This is quick feedback given my experiences installing Python 3 for the
> first time. Take it as that, please.
[...]
> A quick search on the topic found a discussion about this in '05
> without a conclusion, and the following text in PEP
On 01/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > As of 4:50 PM EST, the links to Windows installers give 404 File Not
> > Found.
> >
> > I gather that they are still in process,
> > and notice that there is no public c.l.p. announcement.
>
>
> I just fixed that. The files were t
On 16/02/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > If you avoided the static CRT, and only used Windows APIs, that would
> > avoid this issue, but that means reimplementing everything -
> > malloc/free, FILE*, stdin/stdout/stderr, etc etc. I don't think anyone
> > is contemplating that
On 16/02/2008, Christian Heimes <[EMAIL PROTECTED]> wrote:
> In the last months Amaury, Martin von Löwis and I have done most of the
> Windows work. Any help from an experienced Windows developer is greatly
> appreciated! We *need* an additional Windows developer.
Is there a list anywhere of tasks
On 16/02/2008, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> On Sat, 16 Feb 2008 12:40:52 -0500, Phillip J. Eby wrote:
>
> >>BTW: is there a long-time plan to make the Python core *not* link
> >>against msvcrt dll anymore but only rely on Windows APIs (or maybe also
> >>the static C runtime, I don't r
On 10/02/2008, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Now, we have one and only one chance to slim-down the mapping API, leaving
> the copy()
> function as the one, universal, preferred way to do it. I don't think this
> chance will come
> again.
This discussion confused me (largely bec
On 07/02/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:52 AM 2/8/2008 +1300, Greg Ewing wrote:
> >Would it be feasible for it to always start up as a gui
> >app, and then create its own console window (a fake one
> >if necessary) if it decides it needs one?
>
> No, because that would make
On 06/02/2008, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Nice, it's an elegant and easy solution to the problem. I like to get a
> quite similar solution into the core but I propose a slightly different
> path.
>
> Like your launcher.c, spam.exe looks for spam.py. It additionally looks
> for sp
Whoops, that was meant to go to the list. Sorry.
On 03/02/2008, Brett Cannon <[EMAIL PROTECTED]> wrote:
> But we need a solution, not a start. While the stdlib is bloated, it
> is being trimmed down in Py3K already. If you want to trim more then
> push for stuff to be removed on a module-to-module
On 08/01/2008, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008, at 7:54 AM, J. Clifford Dyer wrote:
> > Aside from the concerns of a few developers wanting simpler release
> > cycles, this is definitely not the way to go.
>
> I don't mean that "political" (in this case, "business") reasons a
On 07/01/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jan 6, 2008, at 1:35 PM, Jim Fulton wrote:
>
> > Really, I'd like to see a much smaller standard library. IMO, pickle
> > isn't essential enough to be part of the standard library and I'
On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Paul Moore schrieb:
> > On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> hashcollision schrieb:
> >> > I request the addition of prod():
> >> It would have to be called product(
On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
> hashcollision schrieb:
> > I request the addition of prod():
> It would have to be called product(), and I believe it has been proposed
> multiple times and been rejected under the "not every 3-line function
> has to be builtin" rule.
Please
On 05/01/2008, Michele Simionato <[EMAIL PROTECTED]> wrote:
> I would like to know if docutils has been ported to Python 3.0 and if
> yes where I can download the code.
That would be a question for the docutils development list -
[EMAIL PROTECTED]
Paul.
___
On 10/12/2007, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Is there an example where you would use post-import hooks even though
> the system didn't support lazy import? The best I can come up with is
> "Don't import module X just for me, but *if* someone else imports it,
> then I want to do these thi
On 06/12/2007, Brett Cannon <[EMAIL PROTECTED]> wrote:
> So if this sounds interesting to you and you want to help me, let me know.
I'm willing to help, but short of free time (you've seen the effects
of this from me before, Brett :-)). I'd be happy to look at Windows
compatibility issues (Python
On 30/11/2007, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> >> class Example:
> >>implements(IExample)
>
> This frame hacking is also a pretty common feature of other types of
> systems, such as ORMs. It can make certain Python code much more
> readable, so "frame hacking" is clearly a useful fea
On 21/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Paul Moore wrote:
> > > Cool. I'm downloading now, and will report back.
> >
> > How is it going? Does the PCbuild9 directory wo
On 21/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > Cool. I'm downloading now, and will report back.
>
> How is it going? Does the PCbuild9 directory work with the final version
> of VS C++ Express?
I couldn't install at work (don&#
On 21/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Not that it changes anything, but VS 2008 it was released today.
> > Cheers,
>
> Nice :)
>
> You can get more information at
> http://msdn2.microsoft.com/en-us/vstudio/products/default.aspx
>
> The express edition is available at
> http
On 20/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> [snip]
> > I will help in addressing this issue, but I am limited in my ability
> > to do so, as I cannot build Python itself (that *does* need full VS
> > 2005/2008, as I understand it
On 20/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> PPS I *will* see what the current status of msvcr8/9 support in the
> Mingw project is, but I'm not too hopeful - mingw is currently
> undergoing a change of maintainers and progress has slowed a lot.
Apologies. I had
On 20/11/2007, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> If someone already understands the rules for mixing CRT's and has a
> reason to do it then more power to them (I do it at work all the time
> due to toolset limitations). On the other hand, if someone doesn't
> understand the restrictions, th
On 20/11/2007, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Am I missing something? Should we lift the restrictions we impose on
> compilers of extension modules? Can we carefully design the Python API
> to accept different compilers/runtime?
I have done similar experiments in the past. There
On 20/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
> the default compiler once it has been released, too?
>
> In other words: Do we want to support outdated compilers for legacy
> reasons or can we stick to 2005 as th
On 20/11/2007, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I think the concern is also about shells other than command.com,
> such as 4NT (can you set COMSPEC to the PowerShell?). If you google
> for it, you find that people do use 4NT, and apparently also make
> COMSPEC point to it.
I certainl
On 15/11/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Ideally, the clean step should not depend on Python existing. On Unix
> it doesn't need it!
>From a quick look, rmpyc.py is deleting .pyc and .pyo files in ..\Lib.
This could be done (I believe) using simply
cd ..\Lib
del /S *.pyc
On 04/11/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm beginning to settle on the following:
>
> 1. concrete types: bytes (immutable) and bytearray (mutable)
bytearray seems a bit clumsy, but I can't think of anything better...
> 2. their common ABC: ByteString (derives from Sequence)
On 03/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> You are partly right. The documentation needs an update. It should say
> "which mist be a list, string, byte sequence or iterable ...".
Actually, "string" is a holdover from the Python 2.x behaviour you
point out below. In 3.x, strings a
On 03/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 03/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > No, it was a bug in the C code. 'H' represents a 16bit type. The correct
> > result is
>
> Ah, I misunderstood what the documentation wa
On 03/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> No, it was a bug in the C code. 'H' represents a 16bit type. The correct
> result is
Ah, I misunderstood what the documentation was getting at. Thanks.
Paul.
___
Python-3000 mailing list
Python
On 03/11/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP
> 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:
>
> test_arra
On 26/09/2007, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > The array module is built in, so it's
> > written in C - what needs to be exposed to qualify as a "C API"?
>
> I think he's referring to the fact that there is no
> pub
On 22/09/2007, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> If it is decided to make bytes immutable (which sounds good to me),
> then I want to add my voice to those that clamor for an additional
> mutable object capable of allocating chunks of memory.
>
> This object should have a C-API and have
On 22/09/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Can we stop this already? The idea is dead. No need to drag it through
> the mud around town for an extended period of time.
It's not dead, it's just pining for the fjords.
Sorry, couldn't resist :-)
Paul.
__
On 21/09/2007, Jim Jewett <[EMAIL PROTECTED]> wrote:
> If you are using text (as opposed to bytes), then À can be either
> U+00C0 or . If the file system makes a distinction,
> then it is using bytes, and any program interacting with it needs* to
> use bytes too.
OK. I don't know enough about Uni
On 21/09/2007, Jim Jewett <[EMAIL PROTECTED]> wrote:
> (Outside ASCII), if you treat sys.argv as text, that is probably
> impossible without filesystem support. Before python even sees the
> data, the terminal itself is allowed to change between canonical
> equivalents, which have different binary
On 16/09/2007, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Sep 15, 2007, at 10:00 PM, Nicholas Bastin wrote:
> > Then lets stop beating around the bush and implement an immutable
> > bytes type. Why put ourselves through contortions trying to jam a
> > square peg into a round hole and not just deci
On 15/09/2007, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> similarly for the environment. os.environ dict
> should be bytes object keys and values
You can't have bytes as keys - the type isn't hashable...
Paul
___
Python-3000 mailing list
Python-3000
On 11/09/2007, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > 3.0: 10 loops, best of 3: 6.76 sec per loop
> > > 2.6: 10 loops, best of 3: 2.61 sec per loop
> >
> > I can't quite reproduce these results. On a 3.2GHz Pentium 4,
> > running
On 10/09/2007, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> svnmerge should come with svn, nowadays, or you can download it separately
> (as svnmerge.py, probably; it's just a Python script.)
It's not part of the Win32 binary distribution for Subversion - but I
found it at http://www.orcaware.com/s
On 10/09/2007, Eric Smith <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> >> I have a patch to add __format__ to datetime.time, .date, and .datetime.
> >> For non-empty format_spec's, I just pass on to .strftime. For empty
> >> format_spec's, it returns str(self).
> >>
> >> I think this is
On 06/09/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> I haven't read it, but it seems very similar to the new annotations
>> capability in py3k (pep 3107). Will that not suffice?
>
> Which I notice has a "Requires: 362" field. Perhaps you're good to go. ;-)
Apparently not (yet,
On 05/09/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> Rather than resurrecting the old RSA-copyright md5.c I can easily make new
> ones out of the libtomcrypt md5 and sha1 sources the same way i created the
> non-openssl sha256 and sha512 modules.
Which reminds me - when I build Python 3 (on
On 26/08/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > On 8/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > I believe the only reasonable solution is to promote the use of
> > package managers, and to let go of the "batteries included" philosophy
>
> It's important to realize that most
On 25/08/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 8/25/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> > On Aug 25, 2007, at 9:36 AM, Guido van Rossum wrote:
> > > FYI, I'm removing the email package from the py3k branch for now.
> > > If/when Barry has a working version we'll add it back. Give
On 22/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > * Add Demo/classes/Rat.py to the stdlib?
>
> Yes, but it needs a makeover. At the very least I'd propose the module
> name to be rational.
If no-one else gets to this, I might take a look. But I'm not likely
to make fast progress as I do
On 23/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Coerce is definitely dead.
>
> cmp() is still alive and __cmp__ is used to overload it; on the one
> hand I'd like to get rid of it but OTOH it's occasionally useful. So
> it'll probably stay. However, to overload <, == etc. you *have* to
>
Can I just check - is __cmp__ due for removal in Py3K? There's no
mention of it in PEP 3100, but its status seems unclear from
references I've found.
Actually, is __coerce__ still around, as well? Again, I can't see a
clear answer in the PEPs or list discussions.
Paul.
___
On 16/08/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Christian Heimes wrote:
> > look at Objects/typeobject.c and grep for PyMethodDef object_methods[]
>
> I should have mentioned that's among the things I've already tried.
[...]
> You don't see the methods in typeobject.c (__mro__, etc).
__mro__
On 16/08/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Currently these particular examples aren't the syntax supported by the PEP.
> It's an alternative/possibly syntax only if there is enough support for a
> serial left to right specification pattern as outlined.
Ah, I hadn't realised that. I've bee
On 15/08/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> EXAMPLES:
>
[...]
> Examples from python3000 list:
[...]
Can I suggest that these all go into the PEP, to give readers some
flavour of what the new syntax will look like?
I'd also repeat the suggestion that these examples be posted to
comp.lang.p
On 14/08/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Then why not have something more readable like
>
>al;s+;w15;d2
A brief sanity check freom someone who is not reading this thread, but
happened to see this post (and it's *not* a dig at Walter, just a
general comment):
If that's *more* r
On 13/08/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > and you set the newline argument to specify a *specific*,
> > non-universal, newline value
>
> It still seems wrong to not translate the newlines, though,
> since it's still a *
On 11/08/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Try h[0:1] == b'P'. Slicing will ensure it stays as a bytes object,
> rather than just giving the integer it contains.
Ugh. Alternatively, h[0] == ord('P') should work.
Unless you're writing source in EBCDIC (is that allowed?).
All of the alt
On 12/08/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Note that Python does nothing special in the above case. For non-Windows
> platforms, you'd get two different results -- the conversion from \r\n to
> \n is done by the Windows C runtime since the default open() mode is text
> mode.
>
> Only w
On 11/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/11/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > Is this ok: when newline='\r\n' or newline='\r' is passed, only that
> > string is used to determine
> > the end of lines. No translation to '\n' is done.
>
> I *think* it would be more
On 07/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> > I wanted to look into this and noticed that 'import time' on Windows
> > doesn't work anymore on my machine. The reason is that
> > PyUnicode_FromStringAndSize()
> > is called for th
On 19/07/07, Aurélien Campéas <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 13, 2007 at 01:41:47PM -0400, Phillip J. Eby wrote:
> > At 07:39 AM 7/13/2007 +0200, Michele Simionato wrote:
> > >But I want to ask your opinion first, in order to understand if you
> > >are willing to scale down your proposal
On 19/07/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The only approach to retroactive generification that I approve of is
> replacing the entire object with a wrapper of sorts, e.g.
>
> foo = generify(foo)
Which (again, just to clarify) means that you would require that
generic functions b
On 17/07/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
>def write(self, s: str):
>if self.closed:
>raise ValueError("write to closed file")
>if not hasattr(s, 'encode')
>raise TypeError("str expected, got %r" % s)
>...
>
> ? It explains what is
On 03/07/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> I also find the semantic make more sense too. For example:
>
> >>> s = StringIO("Good bye, world")
> >>> s.truncate(10)
> >>> s.write("cruel world")
> >>> s.getvalue()
> ???
>
> I think that should return "Good bye, cruel worl
On 24/06/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> Count me as +0 on allowing a.b, and -1 on allowing a.b unless b
> contains leading underscores.
Rereading that, the second part didn't make sense. Assuming a.b is
allowed, I'm -1 on putting restrictions on b, specifically
On 24/06/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 6/20/07, Greg Falcon <[EMAIL PROTECTED]> wrote:
> > This sounds exactly right to me. I don't have strong feelings either
> > way about attribute lookups in formatting strings, or the security
> > problems they raise. But while it seems a r
On 14/05/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm not sure what language you would specifically like to see added to
> the PEP. "Recommendation for 3rd party frameworks: please don't use
> the stick approach." sounds a little strange. What's the point you're
> trying to get across?
So
On 11/05/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 5/11/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> > Hmm. My view is that it *is* simple to explain, but unfortunately
> > Phillip's explanation in the PEP is not that simple explanation :-(
>
> [snip]
On 12/05/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Here's a new version of the ABC PEP. A lot has changed; a lot remains.
> I can't give a detailed overview of all the changes, and a diff would
> show too many spurious changes, but some of the highlights are:
As a general comment, I like t
On 11/05/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I'm now even more of the opinion that this is too
> complicated for Python's first generic function system.
> "If it's hard to explain, it's probably a bad idea."
Hmm. My view is that it *is* simple to explain, but unfortunately
Phillip's explan
On 10/05/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> By the way, I have gotten off-list notes of encouragement from a
> number of people who've said they hope the PEP makes it, so evidently
> it's not overwhelming to everyone. Unfortunately, it seems to be
> suffering a bit from Usenet Nod Syn
On 09/05/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Maybe the tool has gotten smart enough to avoid constructions like:
>
> for k, v in list(dict.items()):
>
> for i in list(range(10)):
>
> but I can't help feeling there will always be a few cases where it
> makes the code longer and worse
On 08/05/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> I will be unhappy if 2to3 produces code that I can't run in (at least)
> 2.6, because then I would need to convert more than once.
IIUC, the idea is that you should be able to write valid Python 2.6
code which 2to3 can convert automatically. The
> - Implement TimSort for BLists, so that best-case sorting is O(n)
> instead of O(log n).
Is that a typo? Why would you want to make best-case sorting worse?
Paul.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listi
On 30/04/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > 6) that doesn't freeze all of the key APIs in concrete
>
> After 15 years of experience with the key APIs, we could perhaps freeze some
> of
> them?
After 15 years not being able to clearly state what "file-like" or
"mapping-like" means to
On 25/04/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote:
> I disagree. I think that B&D-ish enforcement of ABCs is the most important
> feature of an ABC (with the option of being able to turn off enforcement on
> a per-class basis).
OK. We can agree to disagree. My point was that as
On 25/04/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Do we really need to have B&D-ish enforcement of abstract
> method implementation? It doesn't seem pythonic to me.
> I might want to leave some methods of an ABC unimplemented
> because I'm not intending to use them. I'd be annoyed if
> I were pr
On 23/04/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Here you go:
[...]
> Any questions? :)
No :-)
I really do think that putting this in a PEP as it is, would be a good start.
> That's pretty much it, for the generic function part. The interface part
> looks like the "recombinable interfa
On 23/04/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> (It occurs to me that I should mention that, just like the relationship
> between 'type' and 'object' rarely matters unless you delve into
> metaclasses or other wizardry, so too am I referring here only to the
> wizard-level aspects of a gen
On 16/03/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> There aren't many people that write UR"WTF?" either, but odd
> capitalisation is still legal syntax that can't be ignored completely
> when making changes.
>
> Compare:
>
> 0t755 0T755
> 0o755 0O755
> 0c755 0C755
>
> 0c755 is looking like
On 14/03/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Patrick Maupin" <[EMAIL PROTECTED]> wrote:
> > Thanks for the feedback. For some reason, my post hasn't garnered
> > that much attention yet. Do I need to post it on python-dev or
> > c.l.p., or are people just really busy with other thi
On 27/02/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/27/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> [...]
> > Documenting the revised open() factory in this PEP would be useful. It
> > needs to address encoding issues, so it's not a simple copy of the
On 26/02/07, Mike Verdone <[EMAIL PROTECTED]> wrote:
> Daniel Stutzbach and I have prepared a draft PEP for the new IO system
> for Python 3000. This document is, hopefully, true to the info that
> Guido wrote on the whiteboards here at PyCon. This is still a draft
> and there's quite a few decisio
1 - 100 of 156 matches
Mail list logo
