Steven Bethard wrote:
> Pierre Barbier de Reuille wrote:
> > Proposal
> >
> >
> > First, I think it would be best to have a syntax to represent symbols.
> > Adding some special char before the name is probably a good way to
> > achieve that : $open, $close, ... are $ymbols.
>
> How about
Pierre Barbier de Reuille wrote:
> Proposal
>
>
> First, I think it would be best to have a syntax to represent symbols.
> Adding some special char before the name is probably a good way to
> achieve that : $open, $close, ... are $ymbols.
How about using the prefix "symbol." instead of "
Pierre Barbier de Reuille wrote:
> Rocco Moretti a écrit :
> [...]
>
>>
>>I did, but I still don't see why it is an argument against using
>>strings. The point you may not appreciate is that (C)Python already uses
>>strings to represent names, as an important part of its introspective
>>abilities.
Grant Edwards wrote:
> On 2005-11-15, Ben Sizer <[EMAIL PROTECTED]> wrote:
> >
> > myObject.value = 'value1'
> >
> > #... 100 lines of code elided...
> >
> > if myObject.value == 'Value1':
> > do_right_thing()
> > else:
> > do_wrong_thing()
> >
> > I don't actually think string use is 'unte
Rocco Moretti a écrit :
[...]
>
>
> I did, but I still don't see why it is an argument against using
> strings. The point you may not appreciate is that (C)Python already uses
> strings to represent names, as an important part of its introspective
> abilities.
>
Well, I'm well aware of that, bu
On Tue, 15 Nov 2005 21:53:23 +1100, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
[...]
>It isn't always appropriate or necessary to define "constants" (and I
>sometimes wish that Python would enforce assign-once names), but they can
>help avoid some silly mistakes.
(As I'm sure you know) you can have
Björn Lindström wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>
>
>>Why does the byte string "\x6f\x70\x65\x6e\x65\x64" have intrinsic
>>meaning when the int 0 doesn't? It certainly doesn't mean anything to
>>non-English speakers.
>>
>>If all you want is human readable byte strings, then j
On 2005-11-15, Ben Sizer <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>> In the situations described, I always use strings
>> and have never felt the need for something else:
>
> ...
>
>> I don't think I even understand what the objection is. What is
>> needed is a code fragment that shows ho
On Tue, 15 Nov 2005 01:57:53 -0800, Ben Sizer wrote:
>> I don't think I even understand what the objection is. What is
>> needed is a code fragment that shows how the use of strings is
>> untenable.
>
> myObject.value = 'value1'
>
> #... 100 lines of code elided...
>
> if myObject.value = 'Val
Grant Edwards wrote:
> In the situations described, I always use strings
> and have never felt the need for something else:
...
> I don't think I even understand what the objection is. What is
> needed is a code fragment that shows how the use of strings is
> untenable.
myObject.value = 'value1
Björn Lindström <[EMAIL PROTECTED]> wrote:
> So, I guess no one read my explanation of why this an issue about
> more than implementing enums (which is fairly trivial, as we have
> seen).
I read it. I see that something more than enums is being asked for.
What I don't see is a use case where this
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Nov 2005 17:15:04 +0100, Pierre Barbier de Reuille wrote:
> > The key point that, I think, you misunderstand is that symbols are
> > not *variables* they are *values*.
>
> Python doesn't have variables. It has names and objects.
That seems t
Björn Lindström wrote:
> So, I guess no one read my explanation of why this an issue about more
> than implementing enums (which is fairly trivial, as we have seen).
I read it. I don't see that it is an issue, and I
especially don't see why it is relevent to Pierre's
usage of symbols.
In your
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Why does the byte string "\x6f\x70\x65\x6e\x65\x64" have intrinsic
> meaning when the int 0 doesn't? It certainly doesn't mean anything to
> non-English speakers.
>
> If all you want is human readable byte strings, then just use them:
>
> class MyFile:
On 2005-11-14, Rocco Moretti <[EMAIL PROTECTED]> wrote:
>
>> Please, note that I am entirely open for every points on this proposal
>> (which I do not dare yet to call PEP).
>
> I still don't see why you can't just use strings.
Same here. In the situations described, I always use strings
and have
On Mon, 14 Nov 2005 17:15:04 +0100, Pierre Barbier de Reuille wrote:
> The problem is not about having something constant !
> The main point with symbols is to get human-readable values.
> Let say you have a symbol "opened" and a symbol "closed". The state of a
> file may be one of the two.
>
> I
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> The problem is not about having something constant !
> The main point with symbols is to get human-readable values.
> Let say you have a symbol "opened" and a symbol "closed". The state
> of a file may be one of the two.
from some_enum_mod
Rocco Moretti wrote:
> Pierre Barbier de Reuille wrote:
>> Please, note that I am entirely open for every points on this proposal
>> (which I do not dare yet to call PEP).
>
> I still don't see why you can't just use strings.
As does Guido.
Reinhold
--
http://mail.python.org/mailman/listinfo/py
Pierre Barbier de Reuille wrote:
> Please, note that I am entirely open for every points on this proposal
> (which I do not dare yet to call PEP).
I still don't see why you can't just use strings. The only two issues I
see you might have with them are a) two identical strings might not be
identi
Ben Finney a écrit :
> Michael <[EMAIL PROTECTED]> wrote:
>
>>Ben Finney wrote:
>>
>>>I've yet to see a convincing argument against simply assigning
>>>values to names, then using those names.
>>
>>If you have a name, you can redefine a name, therefore the value a
>>name refers to is mutable.
>
>
Michael <[EMAIL PROTECTED]> wrote:
> Ben Finney wrote:
> > I've yet to see a convincing argument against simply assigning
> > values to names, then using those names.
>
> If you have a name, you can redefine a name, therefore the value a
> name refers to is mutable.
Since there are mutable and im
Ben Finney wrote:
> I believe that's exactly what Pierre doesn't want to do. He wants to
> simply use names (marked special in some way) and have Python
> automatically determine a unique value for each name, with nary an
> assignment in sight.
>
> To me, that's a net loss. It makes names more co
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Nov 2005 00:48:46 +1100, Ben Finney wrote:
> > I believe Pierre is looking for a syntax that will save him from
> > assigning values to names; that Python will simply assign
> > arbitrary unique values for these special names.
>
> > What I st
Ben Finney wrote:
...
> I've yet to see a convincing argument against simply assigning values
> to names, then using those names.
I don't like any syntax I've seen so far, but I can understand the problem.
If you have a name, you can redefine a name, therefore the value a name
refers to is mutable
Björn Lindström a écrit :
> Ben Finney <[EMAIL PROTECTED]> writes:
>
>
>>I've yet to see a convincing argument against simply assigning values
>>to names, then using those names.
>
>
> The problem with that is that you can't pass around the names of objects
> that are used for other things. Obv
Steven D'Aprano a écrit :
> On Sun, 13 Nov 2005 12:33:48 +0100, Pierre Barbier de Reuille wrote:
>
>
>>Steven D'Aprano a écrit :
>>[...]
>
>
> If you want to be technical, Python doesn't have variables. It has names
> and objects.
>
> If I want a name x to be bound to an object 1, I have to de
On Mon, 14 Nov 2005 00:48:46 +1100, Ben Finney wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>> On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
>> > The problem, IMHO, is that way you need to declare "symbols"
>> > beforehands, that's what I was trying to avoid by requir
Ben Finney <[EMAIL PROTECTED]> writes:
> I've yet to see a convincing argument against simply assigning values
> to names, then using those names.
The problem with that is that you can't pass around the names of objects
that are used for other things. Obviously they make enums unnecessary,
but on
Ben Finney a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
>
>>Mike Meyer a écrit :
>>
>>>Hmm. You know, $symbol$ doesn't seem nearly as bad as $symbol. It
>>>tickles TeX, not P***. I could live with that.
>>
>>Yep, I like this $symbol$ notation !
>
>
> Gets a big -1 here.
>
>
On Sun, 13 Nov 2005 12:33:48 +0100, Pierre Barbier de Reuille wrote:
> Steven D'Aprano a écrit :
>> On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
>>
>>
>>>The problem, IMHO, is that way you need to declare "symbols"
>>>beforehands, that's what I was trying to avoid by requ
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> Mike Meyer a écrit :
> > Hmm. You know, $symbol$ doesn't seem nearly as bad as $symbol. It
> > tickles TeX, not P***. I could live with that.
> Yep, I like this $symbol$ notation !
Gets a big -1 here.
I've yet to see a convincing argument aga
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
> > The problem, IMHO, is that way you need to declare "symbols"
> > beforehands, that's what I was trying to avoid by requiring a new
> > syntax.
>
> If you don't declare your symbols
Steven D'Aprano a écrit :
> On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
>
>
>>The problem, IMHO, is that way you need to declare "symbols"
>>beforehands, that's what I was trying to avoid by requiring a new syntax.
>
>
> ???
>
> If you don't declare your symbols, how w
On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
> The problem, IMHO, is that way you need to declare "symbols"
> beforehands, that's what I was trying to avoid by requiring a new syntax.
???
If you don't declare your symbols, how will you get the ones that you want?
I don't
Mike Meyer a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
>
>>>While you don't make it clear, it seems obvious that you intend that
>>>if $open occurs twice in the same scope, it should refer to the same
>>>symbol. So you're using the syntax for a dual purpose. $name checks to
>
Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
>>>In LISP : Symbols are introduced by "'". "'open" is a symbol.
>> No, they're not. "'(a b c)" is *not* a symbol, it's a list. Symbols in
>> LISP are just names. "open" is a symbol, but it's normally evaluated.
>> The "'" is syntax that keeps t
Mike Meyer a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
>
>>Please, note that I am entirely open for every points on this proposal
>>(which I do not dare yet to call PEP).
>>
>>Abstract
>>
>>
[...]
>
>
>>Symbols are objects whose representation within the code is mor
Ben Finney a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
>
>>This proposal suggests to add symbols into Python.
>
>
> I still don't think "symbol" is particularly descriptive as a name;
> there are too many other things already in the language that might
> also be called a "sy
On Sat, 12 Nov 2005 18:59:39 +0100, Pierre Barbier de Reuille wrote:
> First, I think it would be best to have a syntax to represent symbols.
> Adding some special char before the name is probably a good way to
> achieve that : $open, $close, ... are $ymbols.
I think your chances of convincing Gu
On Sat, 12 Nov 2005 16:52:12 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote:
[...]
>Personally, I think that the LISP quote mechanism would be a better
>addition as a new syntax, as it would handle needs that have caused a
>number of different proposals to be raised. It would require that
>symbol kno
Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
> Please, note that I am entirely open for every points on this proposal
> (which I do not dare yet to call PEP).
>
> Abstract
>
>
> This proposal suggests to add symbols into Python.
You're also proposing adding a syntax to generate s
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> This proposal suggests to add symbols into Python.
I still don't think "symbol" is particularly descriptive as a name;
there are too many other things already in the language that might
also be called a "symbol".
> Symbols are objects whose r
Please, note that I am entirely open for every points on this proposal
(which I do not dare yet to call PEP).
Abstract
This proposal suggests to add symbols into Python.
Symbols are objects whose representation within the code is more
important than their actual value. Two symbols needs
43 matches
Mail list logo
