[forwarded to the python-ideas list]
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Mon, May 9, 2011 at 18:44, Isaac Morland wrote:
> On Mon, 9 May 2011, Eli Bendersky wrote:
>
> x = 5
>>> def foo ():
>>> print (x)
>>> if bar ():
>>> x = 1
>>> print (x)
>>>
>>>
>> I wish you'd annotate this code sample, what do you intend it to
>> demonstrate?
Michael Urman:
> That screenshot seems to show UTF-8 is being used. This may just be
> the literal bytes in the .c file, but could it be something more
> dependable?
The file is in UTF-8 so the compiler may just be copying the bytes.
There is a setlocale pragma but that seems to be just for st
On Mon, May 9, 2011 at 23:09, Neil Hodgson wrote:
> Michael Urman:
>
>> I'm not convinced this is correct for this case. GetProcAddress takes
>> an "ANSI" string, meaning while it could theoretically use UTF-8, in
>> practice I doubt it uses anything outside of ASCII safely. So while
>> the name o
Michael Urman:
> I'm not convinced this is correct for this case. GetProcAddress takes
> an "ANSI" string, meaning while it could theoretically use UTF-8, in
> practice I doubt it uses anything outside of ASCII safely. So while
> the name of the library would be encoded in UTF-16, the name of the
On Mon, May 9, 2011 at 20:08, Neil Hodgson wrote:
> Yes, Windows will use UTF-16 as it does for almost everything. From
> a user's point of view, these should both just be seen as Unicode.
I'm not convinced this is correct for this case. GetProcAddress takes
an "ANSI" string, meaning while it c
R. David Murray writes:
> On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson
> wrote:
> > *cough* http://mercurial.selenic.com/wiki/GraphlogExtension
>
> I'm sorry, but I've looked at the output of that and the mental overhead
> has so far proven too high for it to be of any use to me.
On Tue, May 10, 2011 at 01:28:04PM +1200, Greg Ewing wrote:
> Marvin Humphrey wrote:
>
>> incremented: The caller has to account for an additional refcount.
>> decremented: The caller has to account for a lost refcount.
>
> I'm not sure that really clarifies anything. These terms
> sound like t
On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson
wrote:
> 2011/5/9 R. David Murray :
> > On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson g> wrote:
> >> I thought the whole point of merging was that you brought a changeset
> >> from one branch to another. This why I just write "merge"
On Tue, May 10, 2011 at 12:13:47PM +1200, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> One interesting aspect is that from the caller's point of view, a
>> *new* reference to the relevant behaves like a borrowed reference for
>> input parameters, but like a stolen reference for output parameters
>>
Marvin Humphrey wrote:
incremented: The caller has to account for an additional refcount.
decremented: The caller has to account for a lost refcount.
I'm not sure that really clarifies anything. These terms
sound like they're talking about the reference count of the
object, but if they cor
Victor Stinner:
> I read these documents but they don't explain which encoding is used in
> libraries and programs. Does it mean that Windows and Linux may use
> different encodings?
Yes, Windows will use UTF-16 as it does for almost everything. From
a user's point of view, these should both j
Le mardi 10 mai 2011 à 09:52 +1000, Neil Hodgson a écrit :
>Some C and C++ implementations currently allow non-ASCII
> identifiers and the forthcoming C1X and C++0x language standards
> include non-ASCII identifiers. The allowed characters are specified in
> Annexes of the respective standards.
Nick Coghlan wrote:
One interesting aspect is that from the caller's point of view, a
*new* reference to the relevant behaves like a borrowed reference for
input parameters, but like a stolen reference for output parameters
and return values.
I think it's less confusing to use the term "new" o
On Mon, 09 May 2011 16:11:15 +0200
Victor Stinner wrote:
> Le lundi 09 mai 2011 à 09:00 -0400, Jim Jewett a écrit :
> > Are you asserting that all foreign modules (or at least all handled by
> > this) are in C, as opposed to C++ or even Java or Fortran? (And the C
> > won't change?)
>
> C and C+
Victor Stinner:
> C and C++ identifiers are restricted to ASCII. I don't know for Fortran
> or Java.
Some C and C++ implementations currently allow non-ASCII
identifiers and the forthcoming C1X and C++0x language standards
include non-ASCII identifiers. The allowed characters are specified in
2011/5/9 R. David Murray :
> On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson
> wrote:
>> I thought the whole point of merging was that you brought a changeset
>> from one branch to another. This why I just write "merge" because
>> otherwise you're technically duplicating information that is
On 5/9/2011 1:54 PM, R. David Murray wrote:
If I do 'hg log' and search for a revno (that I got from hg annotate),
the commit message describing the change is not attached to that revno,
nor as far as I know is there a tool that makes it easy to get from that
revno to the explanatory commit mess
On 5/9/2011 4:05 PM, Guido van Rossum wrote:
On Mon, May 9, 2011 at 12:36 PM, Eric Smith wrote:
On 05/09/2011 03:17 PM, Guido van Rossum wrote:
While my own preference is "make X properly raise an exception" I'm
happy with any of the alternatives proposed here, and grateful to
Terry for call
On Mon, May 9, 2011 at 12:36 PM, Eric Smith wrote:
> On 05/09/2011 03:17 PM, Guido van Rossum wrote:
>> On Mon, May 9, 2011 at 11:36 AM, Ned Batchelder
>> wrote:
>>> On 5/9/2011 1:24 PM, Terry Reedy wrote:
A commit (push) partition time and behavior into before and after (with a
s
On 05/09/2011 03:17 PM, Guido van Rossum wrote:
> On Mon, May 9, 2011 at 11:36 AM, Ned Batchelder
> wrote:
>> On 5/9/2011 1:24 PM, Terry Reedy wrote:
>>>
>>> A commit (push) partition time and behavior into before and after (with a
>>> short change period in between during which behavior is undef
On Mon, May 9, 2011 at 11:36 AM, Ned Batchelder wrote:
> On 5/9/2011 1:24 PM, Terry Reedy wrote:
>>
>> A commit (push) partition time and behavior into before and after (with a
>> short change period in between during which behavior is undefined).
>>
>> Some commit messages have the form 'x does y
On 5/9/2011 1:24 PM, Terry Reedy wrote:
A commit (push) partition time and behavior into before and after
(with a short change period in between during which behavior is
undefined).
Some commit messages have the form 'x does y'. Does 'does' mean before
or after? Sometimes that is clear. 'x cr
On Mon, 09 May 2011 17:55:42 +0200, =?UTF-8?Q?=C3=89ric_Araujo?=
wrote:
> Le 09/05/2011 16:08, Benjamin Peterson a écrit :
> > 2011/5/9 Victor Stinner :
> >> For merge commits: many developers just write "merge" or "merge
> >> 3.1". I
> >> have to go to the parent commit (and something to the g
Éric Araujo netwok.org> writes:
> Yep, probably dead code. I think that an handler should be defined
> only once, in the “if __name__ == '__main__'” block. Am I right? Just
> like you don’t call sys.exit from library code (hello optparse!), you
> don’t set logging handlers in library c
A commit (push) partition time and behavior into before and after (with
a short change period in between during which behavior is undefined).
Some commit messages have the form 'x does y'. Does 'does' mean before
or after? Sometimes that is clear. 'x crashes' means before. 'x return
correct va
On 5/9/2011 9:27 AM, Stefan Behnel wrote:
Eli Bendersky, 09.05.2011 14:56:
It's a known Python gotcha (*) that the following code:
x = 5
def foo():
print(x)
x = 1
print(x)
foo()
Will throw:
UnboundLocalError: local variable 'x' referenced before assignment
On the usage of 'x' in the *first*
Hi,
When it comes to
containers, identity matters at least as much as value does (and
sometimes more so - e.g. sys.modules). Replacing those global
containers with new ones isn't guaranteed to work, as they may be
cached in various places rather than always retrieved fresh from the
relevant modu
Eli Bendersky wrote:
I think you are making an unwarranted assumption about what is "more
expected". I presume you are thinking that the expected behaviour is that
foo() should:
print global x (5)
assign 1 to local x
print local x (1)
If we implemented this change, there would be no more questi
Hi,
Thanks for the help. I didn’t know about handler.close. (By which I
mean that I used logging without re-reading its documentation, which is
a testimony to its usability :)
The cases you refer to seem to be _set_logger in packaging/run.py
(which appears
not to be used at all - there app
Hi,
Le 09/05/2011 16:08, Benjamin Peterson a écrit :
2011/5/9 Victor Stinner :
For merge commits: many developers just write "merge" or "merge
3.1". I
have to go to the parent commit (and something to the grandparent,
3.1->3.2->3.3) to learn more about the commit.
I follow conventions I’ve s
On Mon, 9 May 2011, Eli Bendersky wrote:
x = 5
def foo ():
print (x)
if bar ():
x = 1
print (x)
I wish you'd annotate this code sample, what do you intend it to
demonstrate?
It probably shows the original complaint even more strongly. As for being a
proble
On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson
wrote:
> I thought the whole point of merging was that you brought a changeset
> from one branch to another. This why I just write "merge" because
> otherwise you're technically duplicating information that is pulled
> onto the branch by mergi
On Tue, May 10, 2011 at 1:06 AM, Eli Bendersky wrote:
> It probably shows the original complaint even more strongly. As for being a
> problem with the suggested solution, I suppose you're right, although it
> doesn't make it much different. Still, before a *possible* assignment to
> 'x', it should
On Tue, May 10, 2011 at 1:01 AM, Eli Bendersky wrote:
>
>> I think you are making an unwarranted assumption about what is "more
>> expected". I presume you are thinking that the expected behaviour is that
>> foo() should:
>>
>> print global x (5)
>> assign 1 to local x
>> print local x (1)
>>
>> I
> x = 5
> def foo ():
>print (x)
>if bar ():
>x = 1
>print (x)
>
I wish you'd annotate this code sample, what do you intend it to
demonstrate?
It probably shows the original complaint even more strongly. As for being a
problem with the suggested solution, I
On Mon, May 9, 2011 at 11:00 PM, Jim Jewett wrote:
> Are you asserting that all foreign modules (or at least all handled by
> this) are in C, as opposed to C++ or even Java or Fortran? (And the C
> won't change?)
The extension module that interfaces them to CPython will be written
in C, or somet
> I think you are making an unwarranted assumption about what is "more
> expected". I presume you are thinking that the expected behaviour is that
> foo() should:
>
> print global x (5)
> assign 1 to local x
> print local x (1)
>
> If we implemented this change, there would be no more questions abo
On Sat, May 7, 2011 at 3:51 AM, Éric Araujo wrote:
> regrtest helpfully reports when a test leaves the environment unclean
> (sys.path, os.environ, logging._handlerList), but I think the implementation
> is buggy: it compares object identity and then value. Why is comparing
> identity useful? I’
Eli Bendersky wrote:
Hi all,
It's a known Python gotcha (*) that the following code:
x = 5
def foo():
print(x)
x = 1
print(x)
foo()
Will throw:
UnboundLocalError: local variable 'x' referenced before assignment
I think part of the problem is that UnboundLocalError is a ja
On Fri, May 6, 2011 at 8:27 PM, Antoine Pitrou wrote:
> On Fri, 06 May 2011 13:28:11 +1200
> Greg Ewing wrote:
>
>> Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]:
>>
>> > This is not always true, for example when the item is already present
>> > in the dict.
>> > It's no
Le lundi 09 mai 2011 à 09:08 -0500, Benjamin Peterson a écrit :
> It seems like something that should be solved by tools like a display
> visual graph indicating what is merged. (like Bazaar)
Yeah, we could fix buildbot, hg.python.org website, improve hg log, and
all other tools using Mercurial. B
Le lundi 09 mai 2011 à 09:00 -0400, Jim Jewett a écrit :
> Are you asserting that all foreign modules (or at least all handled by
> this) are in C, as opposed to C++ or even Java or Fortran? (And the C
> won't change?)
C and C++ identifiers are restricted to ASCII. I don't know for Fortran
or Jav
2011/5/9 Victor Stinner :
> Hi,
>
> Commit changelogs are important to understand why the code was changed.
> I regulary use hg blame to search which commit introduced a particular
> line of code, and I am always happy if I can find an issue number
> because it usually contains the whole story.
>
>
On Mon, May 9, 2011 at 2:53 PM, Jim Jewett wrote:
> Can you clarify (preferably in the commit message as well) exactly
> *why* these largefile tests are useless? For example, is there
> another test that covers this already?
Ah, sorry about that. It was discussed on the tracker issue, but I gues
On May 9, 2011 6:59 AM, "Eli Bendersky" wrote:
>
> Hi all,
>
> It's a known Python gotcha (*) that the following code:
>
> x = 5
> def foo():
> print(x)
> x = 1
> print(x)
> foo()
>
> Will throw:
>
>UnboundLocalError: local variable 'x' referenced before assignment
>
> On the u
Eli Bendersky, 09.05.2011 14:56:
It's a known Python gotcha (*) that the following code:
x = 5
def foo():
print(x)
x = 1
print(x)
foo()
Will throw:
UnboundLocalError: local variable 'x' referenced before assignment
On the usage of 'x' in the *first* print. Recently, whi
On Mon, 9 May 2011, Eli Bendersky wrote:
It's a known Python gotcha (*) that the following code:
x = 5
def foo():
print(x)
x = 1
print(x)
foo()
Will throw:
UnboundLocalError: local variable 'x' referenced before assignment
On the usage of 'x' in the *first* print. Recently, wh
On Mon, May 09, 2011 at 08:40:03AM -0400, R. David Murray wrote:
> +1. What I do is, in the edit window for the commit message, I pull
> in .hg/last-message.txt, and just type 'Merge' in front of my previous
Thanks for this tip. I shall start following this one too.
--
Senthil
_
Are you asserting that all foreign modules (or at least all handled by
this) are in C, as opposed to C++ or even Java or Fortran? (And the C
won't change?)
Is this ASCII restriction (as opposed to even UTF8) really needed?
Or are you just saying that we need to create an ASCII name for passing t
Hi all,
It's a known Python gotcha (*) that the following code:
x = 5
def foo():
print(x)
x = 1
print(x)
foo()
Will throw:
UnboundLocalError: local variable 'x' referenced before assignment
On the usage of 'x' in the *first* print. Recently, while reading the
zillionth quest
Can you clarify (preferably in the commit message as well) exactly
*why* these largefile tests are useless? For example, is there
another test that covers this already?
-jJ
On 5/7/11, nadeem.vawda wrote:
> http://hg.python.org/cpython/rev/201dcfc56e86
> changeset: 69886:201dcfc56e86
> branch:
On Mon, 09 May 2011 12:32:48 +0200, Victor Stinner
wrote:
> For merge commits: many developers just write "merge" or "merge 3.1". I
> have to go to the parent commit (and something to the grandparent,
> 3.1->3.2->3.3) to learn more about the commit.
>
> Would it be possible to repeat the changel
Hi,
Commit changelogs are important to understand why the code was changed.
I regulary use hg blame to search which commit introduced a particular
line of code, and I am always happy if I can find an issue number
because it usually contains the whole story.
And since the migration to Mercurial, w
54 matches
Mail list logo
