On Thu, Dec 4, 2008 at 2:36 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I would like to merge mailing lists, now that the design and first
> implementation of Python 3000 is complete. In particular, I would
+1
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is w
On Oct 7, 2008, at 4:06 PM, Martin v. Löwis wrote:
b) I would propose that the notion of a default encoding is entirely
eliminated from Python, along with sys.(get|set)defaultencoding
+1
-Fred
--
Fred Drake
___
Python-3000 mailing list
same module names for different
codebases is a pain. The standard library and the rest of the Python
world shouldn't overlap module names (this is part of why many have
requested a separate namespace for the Python standard library).
-Fred
--
e terribly difficult.
It's also entirely possible that the API isn't interesting if you
don't support existing databases, for many applications.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.py
a happier version.
I think this is worth considering. I vaguely recall that the bsddb
module was maintained before it was incorporated into the core Python
release.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@pytho
On Jun 2, 2008, at 11:59 PM, Guido van Rossum wrote:
Actually I think we won't need that function once we're used to just
passing exception instances around.
Ah, so many differences that I've lost track of. I feel so...
py2k. :-(
-Fred
On May 31, 2008, at 6:42 PM, Tim Delaney wrote:
This reminds me of something I've thought a few times - maybe the
tuple returned from sys.exc_info() should be a named tuple.
+1
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python
my note
that my preferred approach would be that there's no default at all;
the location would have to be specified explicitly. Whether on the
command line or in the distutils configuration doesn't matter, but
explicitness should be required.
ls config
locations) in order to enable per-user installation.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Mac OS X 10.5.2 with no local changes. I did a "make
clean; make; make test" and still get the error. I've no time to look
into it right now.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://m
On Feb 8, 2008, at 7:51 PM, Raymond Hettinger wrote:
> I recommend dropping the dict.copy() method from Py3.0.
+1
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3
ime with that.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
ay in unit
tests.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Guido having a bad typing day? ;-)
I'd be happy seeing these methods added to tuple; there's no reason
that they would only be useful on mutable sequences.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
On Jan 11, 2008, at 10:02 AM, Georg Brandl wrote:
> I'd suggest a single package to unify all this functionality and an
> API
> that makes it easy to go from every compiling stage to the next, or to
> the final code object.
+1
-Fre
brary was
questionable at best (and the tie to PyXML exacerbated that horribly).
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
) reason to
split out packages that aren't essential to make Python a good
language to work with.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Un
of the Python 2 standard library become separate projects.
Hear, hear! Aside from the concerns of the people needing sumo
releases for political reasons, this is definitely the way to go.
-Fred
--
Fred Drake
___
Python-3000 mailing
dding a schema component,
but it's not actually necessary. For zc.buildout, command line
options of the form section:option=value are interpreted as another
configuration file that takes precedence over the ini-format files
that are loaded using
> this
> idea?
Definitely! I'm interested, and suspect others at ZC would appreciate
such a module as well.
Of course, we'd be most interested if it worked with Python 2.4
forward. ;-) I'm certainly willing to
On Dec 6, 2007, at 8:37 AM, [EMAIL PROTECTED] wrote:
> Should the PEP acknowledge this route to module sainthood for certain
> modules?
I think this is out of scope for the PEP. It's fine if the PEP points
to new distributions for the modules as they become available.
-Fre
On Dec 7, 2007, at 6:33 AM, Christian Heimes wrote:
> Is the py3k branch open for development again?
Oops, good question. Wish I'd wondered about that.
/me feels out of sync with the Python development cycle...
-Fred
--
Fr
On Dec 7, 2007, at 1:54 AM, Brett Cannon wrote:
> I say just go ahead and rename it. Other modules are going to need to
> be renamed as well so it isn't like this is going to be a special
> case.
And done.
-Fred
--
Fred Drake
t, I'll go ahead
and do this in the next day or so (to give folks a chance to respond
to this email).
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Uns
e fine for my purposes).
If it moves out of the standard library, I'll volunteer to create a
separate distribution for it (assuming no one beats me to it).
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.
I'd be happy if the "default" behavior on str values is to raise an
exception, rather than ever making a guess silently.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/m
On Oct 29, 2007, at 2:51 PM, Guido van Rossum wrote:
> Makes sense, if you change the 3.x rule to
>
> 3.x __bool__ only.
Even better! I think I'm going to like 3.0 if I ever get a chance to
use it. ;-)
-Fred
--
Fred Drake
2.6 __bool__ first, then __nonzero__ (if patch submitted)
3.x __bool__ first, then __nonzero__
The fewer variations there are in the algorithm, the better.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail
I
print, using the __future__ import only dirties an isolated spot in a
module that prints. Much better, and probably useful during the
transitional period.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.
a problem for this.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
hotshot a few weeks ago, and there was
some uncertainty about whether a decision had been reached. Reading
back over the mails, there were no objections. Python 3.0 seems a
perfect time to rip it out. If there are no objections, I'll do that
this weekend.
-Fred
th an underscore. It's part of the public API for text files.
Amazingly, that's good enough for me. ;-)
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsu
with convenient text-centric wrappers also available. But I'd be
fine with constructing those myself.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscri
a look at it as soon as I can, but won't object if someone
beats me to it.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/m
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 decide to make a round peg?
+42
-Fred
--
F
ective, they should
work, but they should be removed from source code (I've never *like*
the __future__ imports, though I understand their value).
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.pyt
makes it easier to avoid re-using a feature name; I
think there's merit in that.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.pyth
ad of None when they aren't used in the signature?
Also, the post-history is blank; perhaps this still needs to be
presented to the community for review and discussion? Or perhaps the
field in the PEP needs to be filled in.
-
xact
topic. Watch for conflicts. My changes were mostly removals and
minor updates; I'm sure there's more to be done.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listi
On Aug 29, 2007, at 10:19 PM, [EMAIL PROTECTED] wrote:
> You can achieve these sorts of effects by assigning an object to
> sys.modules[modulename].
Only for imports that haven't happened yet, which tends to be fragile.
-Fred
--
r for applications to pick up
bug fixes.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
ad the emails,
PEPs, blogs(!) and what-not related to it. From where I stand, I'm
not yet certain that 2.5 is real. ;-/
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listin
On Aug 16, 2007, at 12:38 PM, Guido van Rossum wrote:
> I use it in the same way we used to refer to Python 3000 in the
> past. :-)
If we acknowledge that Python 3.0 isn't the same as Python 3000, we
don't even need a new name for it. ;-)
-Fred
t case.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
l be much more common than the need
for mutable bytes objects from literal data in my own code.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscri
for the email package should be left to the email-sig as
well, I suspect. It's good that they've come up.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinf
On Aug 5, 2007, at 4:49 PM, Martin v. Löwis wrote:
> I don't think it needs to be a separate type,
> instead, bytes objects could have a idem-potent
> .freeze() method which switches the "immutable"
> bit on. There would be no way to switch it off
> again.
pect that consistency
isn't the underlying motivation.
-Fred
--
Fred Drake
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
48 matches
Mail list logo
