"Martin v. Löwis" writes:
> > The basic idea is to allocate code points in private space as-needed.
>
> Ok, thanks. Would you be interested in implementing that scheme?
Yes. I'm recovering from moving from Japan to California, and will be
busy until the beginning of October, I'll get started
Guido van Rossum wrote:
> It is possible to compromise the integrity of a built-in type by
> subclassing it if the type wasn't carefully written to expect
> subclassing.
Disallowing subclassing in Python may make sense, but
it seems unreasonable not to allow subclassing by
consenting C code that i
Thomas Wouters wrote:
> If you want to put more meaning in the argv list, use an option
> parser.
I want to put *less* meaning in it, not more. :-)
And using an argument parser is often overkill for
simple programs.
> The _actual_ meaning of each element depends entirely on the
> program that's
Larry Hastings wrote:
> If nothing else, at least we could fix the proviso for argv[0]: "(it is
> operating system dependent whether this is a full pathname or not)."
It's actually worse than that -- you're entirely at the
mercy of whatever made the exec() call as to whether it's
a meaningful p
On 16-Sep-07, at 7:56 PM, Guido van Rossum wrote:
> So suppose my answer was "no, bytes won't be subclassable". How much
> would you really lose by having to wrap a separate object around a
> bytes object, rather than being able to subclass? How much extra code
> do you think you would have to writ
On 9/16/07, Mathieu Fenniak <[EMAIL PROTECTED]> wrote:
> On 16-Sep-07, at 12:38 PM, Guido van Rossum wrote:
> > I'm not doubting that *your* subclass works well enough. The problem
> > is that it must robust in the light of *any* subclass, no matter how
> > crazy.
>
> I understand that, but I'm not
Guido van Rossum wrote:
> This sounds awfully close to bikeshedding.
I don't agree with that assessment. This is something
I've had in mind for quite a while. Python optimises
this for the *least* frequent use case, which is just
plain silly, as far as I can see. The only reason for
it is because
Paul Moore wrote:
> 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...
Has there been any consensus reached yet on whether
there will
Gregory P. Smith wrote:
> argv is the C/C++ name for bytes, lets not
> confuse people.
C has never made a clear distinction between characters
and bytes, using the type 'char' for both. It got away
with it for the same reason that Python did until
unicode came along. I'm pretty sure most people us
On 16-Sep-07, at 12:38 PM, Guido van Rossum wrote:
> I'm not doubting that *your* subclass works well enough. The problem
> is that it must robust in the light of *any* subclass, no matter how
> crazy.
I understand that, but I'm not sure what kind of problems can be
created by crazy subclasses.
On 9/16/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> 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 t
"Sascha Peilicke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| is or has there been any discussion about stackless and py3k?
No. C. Tismer has focused his current efforts on PyPy.
___
Python-3000 mailing list
Python-3000@python.or
On 9/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think it's not so obvious that reversing the order is any better
> when you throw in some if clauses:
>
> [friend for city in cities if city.name != "Amsterdam" for friend in
> city.friends if friend.name != "Guido"]
>
> vs.
>
> [friend fo
I think it's not so obvious that reversing the order is any better
when you throw in some if clauses:
[friend for city in cities if city.name != "Amsterdam" for friend in
city.friends if friend.name != "Guido"]
vs.
[friend for friend in city.friends if friend.name != "Guido" for city
in cities i
On 9/16/07, Noam Raphael <[EMAIL PROTECTED]> wrote:
> All this is to say that I think that the "for" parts in list
> comprehensions and generator expressions should, in a perfect world,
> be evaluated in the other way round.
This proposal is not really appropriate for the python-3000 list --
it's
Hello,
I had a thought about syntax I want to share with you.
Say you want to get a list of all the phone numbers of your friends.
You'll write something like this:
telephones = [friend.telephone for friend in friends]
Now suppose that, unfortunately, you have many friends, and they are
grouped
It is possible to compromise the integrity of a built-in type by
subclassing it if the type wasn't carefully written to expect
subclassing. The bytes type currently wasn't written to be careful
about this. Why can't you use containment instead of subclassing?
--Guido
On 9/16/07, Mathieu Fenniak <
Hi everyone,
I'd like to be able to derive from the bytes type, but this currently
isn't possible due to it missing the Py_TPFLAGS_BASETYPE. A comment
next to the flags indicates that this class is "sealed / final". I
tried to search this list for some information on this, but I
couldn't
On 9/16/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > Also "argv" sounds more low-level than something like "arguments".
>
> While we're on the subject of argv, I've been wondering
> whether py3k might want to revisit the idea of having
> argv[0] be the program name. In my experience, one almost
> How do you get from "some keys can't be ordered" to "it doesn't make
> sense for Python to have sorteddict or sortedset"? If you want to use
> keys that can't be ordered, then feel free to continue to use dict.
> For situations in which ordering is important, that language should
> support that.
Hello,
is or has there been any discussion about stackless and py3k?
regards,
Sascha Peilicke
--
http://saschashideout.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Python-3000 mailing list
Python-3000@python.org
h
Guido van Rossum wrote:
On 9/15/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
Changing the existing behaviour of argv would probably
be too disruptive, so how about relegating argv to a
low-level detail and providing something else for
everyday use that omits argv[0]?
sys.arguments would sound
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
> The basic idea is to allocate code points in private space as-needed.
Ok, thanks. Would you be interested in implementing that scheme?
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3
"Martin v. Löwis" writes:
> > What I'm suggesting is to provide a way for processes to record and
> > communicate that information without needing to provide a "source
> > encoding" slot for strings, and which is able to handle strings
> > containing unrecognized (including corrupt) characters
25 matches
Mail list logo
