raise_assert(message_expr)". No one
was too interested.
Did I miss anything? I like problems to have accurate final solutions.
Thanks for the time,
Charles
On Thu, Apr 24, 2008 at 9:13 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Charles Merriam wrote:
>>
>> On Thu,
On Thu, Apr 24, 2008 at 2:01 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 24, 2008 at 1:51 PM, Mikhail Glushenkov
> > Why not make ``assert`` a built-in function then?
> Because then it can't be disabled by the compiler in -O mode.
A reasonable conclusion, but needs better reaso
look like.
I do not know if the implementation details of parenthesized tuples
make this difficult. I
should have noticed it a year ago.
Charles Merriam
___
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
On Wed, Mar 26, 2008 at 9:33 PM, Talin <[EMAIL PROTECTED]> wrote:
...
> For new code, however, there is an alternative strategy that doesn't
> involve 2to3 at all, which is to write code in the "greatest common
> subset" of 2.6 and 3.0.
>
> As Lennart Regbro pointed out earlier, this common sub
OK. 54 long messages into it, the argument is stuck at:
1. But 3.0 code is different.
2. But 3.0 shouldn't gratuitously break 2.6 code.
So make u"sting" a deprecated structure with a warning and kill it in
3.1. Why write a novel about it? Just make what programmers expect
to happen happen.
I hate bringing up something that has been hashed over so many times,
but I'm a bear
of little brain and am not understanding the migration path. The
whole use of the "2to3"
tools seems like an abrupt hack. It is workable, but causes a serious
plan for near term
2.x to 3.x migration. I'd like t
e?
On Thu, Mar 20, 2008 at 8:40 AM, Charles Merriam
<[EMAIL PROTECTED]> wrote:
> Hello Lennart,
>
> As you can see by the growing conversation, the matter is a bit old
> and, with age, smells
> bad. I'd like to convince you that it is a bad idea anyway.
>
> Th
Hello Lennart,
As you can see by the growing conversation, the matter is a bit old
and, with age, smells
bad. I'd like to convince you that it is a bad idea anyway.
The problem is not the gratuitous removal of the leading 'u', but the
subtle problems when
the code looks nearly identical. The mo
On Mon, Mar 17, 2008 at 3:37 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> ...
> Can you give another rule that you prefer and that I can comprehend and
> that I can explain to Python newcomers? The OP only gave a few examples of
> * usage and (initially) no rule that I saw.
Really, it is as c
-1.
While the syntax has a basic beauty, it requires too much odd explanation.
"*" and "**" are already binary operators.
The '*' unary operator can confuse migrating programmers already.
It makes puzzles too easy, e.g., yield **[2**3*i, for i in range(2*3**4)]
On Sat, Mar 15, 2008 at 6:55 PM
I agree. A wiki page for "leaving just the head of the snake" would
be the correct solution.
On Feb 4, 2008 4:34 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 2/4/08, Charles Merriam <[EMAIL PROTECTED]> wrote:
> > What about a formal dependency plan instead?
>
his a poor idea? "Hard drive space is
expensive" is not an acceptable argument.
Charles
-
Charles Merriam
e: [EMAIL PROTECTED]
u: http://charlesmerriam.com
q: "Toolboxes have more tools than just a hammer."
On Feb 4, 2008 1:28 AM, Nick Coghlan <[EMAIL PROTECTED]&
uring the early transition period:
...# Require python 3.x
print ("I'm Pythonic!")
The idiom would disappear with time, not add special cruft to the
language, and would give a reasonable compile-time error message.
Just a thought,
Charles
---
Charles Merriam
e: [EMAIL PROTECTED]
u: htt
> There are also « and », << and >> for those w/o UTF-8 support in their
> mail client. On my keyboard the characters are available under [alt gr]
> + y and x.
Not elegant. It should look pretty. Code should look the same in all
character encodings unless alternate codings for used for identifie
OK, I'll admit this is confusing to me.
Is "..." == pass?
So, does a line with tokens after the "..." get an error like
"characters after an elipses (...). Did you cut and paste from IDLE?"
On Jan 24, 2008 12:04 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Some folks thought it would b
Not to be pedantic, but the major concern others are voicing is that
is that queue size is not reliable and is therefore a potential source
of hard to find threading bugs by naive users. Why not just rename
q.size() to the unweildy name of q.est_size()?
On Jan 14, 2008 11:59 AM, Guido van Rossu
t; At 10:55 AM 1/13/2008 -0800, Charles Merriam wrote:
> >You have a legitimate counter-argument that grouping the
> >implementations of __add__ in the metaclass is cleaner than having
> >them stand alone and be referenced in.
>
> You've misunderstood Michele's
implementations of __add__ in the metaclass is cleaner than having
them stand alone and be referenced in. Is this your argument?
Lost,
Charles
On Jan 13, 2008 9:58 AM, Michele Simionato <[EMAIL PROTECTED]> wrote:
> > On Jan 13, 2008 9:37 AM, Charles Merriam <[EMAIL PROTECTED]> wrot
sorry, I meant __new__() not __init__(). For this crowd, I thought
I'd put in the obvious correction. :)
On Jan 13, 2008 9:37 AM, Charles Merriam <[EMAIL PROTECTED]> wrote:
> Well, I'm explicitly dropping this. So far no one has pointed out
> any use cases that
Well, I'm explicitly dropping this. So far no one has pointed out
any use cases that are not equivalent to intercepting an array of the
namespace in the __init__() of a subclass of type, then calling
type's __init__() on the modified namespace. Still, I do get a level
of snarky insults that le
Could you provide some more information? One can define behavior as
simply as wrapping an indirection around each method of a class. I'd welcome
pointers to the additional cases.
Thank you,
Charles
On Dec 22, 2007 4:57 AM, Christian Tanzer <[EMAIL PROTECTED]> wrote:
>
>
>
> Yes, several. You haven't been reading the previous discussion
> threads, in which I've repeatedly posted other use cases for PEP
> 3115, every time someone else who hasn't read the previous posting of
> those use cases, and tries to "simplify" the PEP. Other people have
> posted a few as wel
s really
late to party. I would love to see use cases for which this solution
does not work. Is this a matter of writing a PEP?, writing a sample
cpython patch?, learning to live without?
Charles Merriam
---
Refs:
The PEP
http://www.python.org/dev/peps/pep-3115/
David Mertz's Metaclass
23 matches
Mail list logo
