Re: [Python-Dev] Broken import?

[Nick Coghlan]

Terry Reedy wrote:
> Terry Reedy wrote:
>> Guido van Rossum wrote:
> 
 The reason seems to be that until the outermost import (in this case
 p.b) is completed, while sys.modules has the (incomplete) modules 'p',
 'p.a' and 'p.b', the attributes p.a and p.b aren't added until after
 their import is completed. Which it isn't during recursive import.
 Apparently 'from  import ' looks for the
  attribute in the  object. This is because
 "from...import" can also be used to import objects other than modules
 (e.g. "from M import C"). I'm guessing that setting the attribute is
 delayed until the import is totally complete, because upon a failed
 import we remove the half-imported module object from sys.modules, but
 apparently we didn 't want to be in the business of removing the
 attribute from the parent package, so that's only set after the import
 is deemed successful.
> 
> I remember a pydev discussion on this point.

The quote from Fredrik in Guido's original message sounded familiar.
Checking my nosy list on the tracker brought me to the following issue:

http://bugs.python.org/issue992389

Jim Fulton's example in that tracker issue shows that with a bit of
creativity you can provoke this behaviour *without* using a from-style
import. Torsten Bronger later brought up the same issue that Fredrik did
- it prevents some kinds of explicit relative import that look like they
should be fine.

It's starting to look to me like the "set in advance and delete on
failure" approach taken with sys.modules may make sense for the
attributes in the parent package after all. Given the way that import is
defined, I suspect that is easier said than done though...

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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

Re: [Python-Dev] And the winner is...

[Nick Coghlan]

Mike Coleman wrote:
> Just for curiosity's sake, could someone outline the five (or so) most
> significant pluses of hg relative to git?

Every single git command line example I have seen gives me exactly the
same gut reaction I get whenever I have to read Perl code. You can extol
the tool's virtues to me all day long, but you're never going to
eliminate that visceral horror at its interface, any more than someone
that loves Perl is going to have any luck convincing me that it really
can be a sane choice of language for anything more than
write-once-read-never throwaway scripts.

Note that it *isn't* the idea of a using a directed acyclic graph in
general that bothers me (since all DVCSs are pretty much forced to do
that): it's specifically the way the sensibilities of git's original
audience are reflected in the CLI, and the subsequent offense to my own
personal sense of aesthetics :)

The Mercurial and Bazaar interfaces on the other hand, both seemed
perfectly palatable (e.g. a bit more inclined to use words over arcane
symbols), and Hg appears to be a clear winner against Bazaar when it
comes to performance *right now*. So Guido's intuition actually sounds
perfectly reasonable to me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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

Re: [Python-Dev] Test failures under Windows?

[Kristján Valur Jónsson]

Right, my question to microsoft was more about making sure that a 
__crtMessageBox() actually does nothing, when running unattended as a service.

Also, we should be seeing the same problem in non-debug versions, since the 
_set_invalid_parameter_handler() is no longer called, and the default one also 
puts up a message box.  The Assertion is then performed _in_addition_ on debug 
builds:
>From 
>ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/c0e67934-1a41-4016-ad8e-972828f3ac11.htm
In the following example, an invalid parameter error handler is used to print 
the function that received the invalid parameter and the file and line in CRT 
sources. When the debug CRT library is used, invalid parameter errors also 
throw an assertion, which is disabled in this example using _CrtSetReportMode.

Btw, I am working on finding out the test suite failures for 
test_multiprocessing.
K
-Original Message-
From: Curt Hagenlocher [mailto:c...@hagenlocher.org] 
Sent: 25. mars 2009 12:54
To: Kristján Valur Jónsson
Cc: mhamm...@skippinet.com.au; David Bolen; python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows?

2009/3/25 Kristján Valur Jónsson :
>
> I'm going to poke my contacts at Microsoft and ask them if there is
> a way to disable popups like this for a process that runs unattended
> and/or is running as a windows service.

MSVC has shipped with runtime library source since the 16-bit days, so
the easier thing is just to read the source code.  :)

It looks like there are two possible code paths for the assertion.
The first code path uses functions in dbgrpt[t].c and its behavior is
controlled by CrtSetReportMode and CrtSetReportFile.  The second uses
functions in assert.c and its behavior is controlled by
_set_error_mode.  Both code paths use __crtMessageBox in crtmbox.c to
actually display the message box.  This function -- when running as a
service -- will helpfully set MB_SERVICE_NOTIFICATION before calling
the USER32 MessageBox, which ensures that you'll see exactly why your
service has hung the next time you actually log in with sufficient
rights. :/

The variation that goes through assert.c should write to stderr for a
console-mode application, so it's reasonable to assume that we're
hitting the other code path -- and that Mark's suggestion to use
CrtSetReportMode would address the issue.

--
Curt Hagenlocher
c...@hagenlocher.org

___
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

Re: [Python-Dev] And the winner is...

[Brett Cannon]

2009/3/31 Nick Coghlan 

> Mike Coleman wrote:
> > Just for curiosity's sake, could someone outline the five (or so) most
> > significant pluses of hg relative to git?
>
> Every single git command line example I have seen gives me exactly the
> same gut reaction I get whenever I have to read Perl code. You can extol
> the tool's virtues to me all day long, but you're never going to
> eliminate that visceral horror at its interface, any more than someone
> that loves Perl is going to have any luck convincing me that it really
> can be a sane choice of language for anything more than
> write-once-read-never throwaway scripts.
>
> Note that it *isn't* the idea of a using a directed acyclic graph in
> general that bothers me (since all DVCSs are pretty much forced to do
> that): it's specifically the way the sensibilities of git's original
> audience are reflected in the CLI, and the subsequent offense to my own
> personal sense of aesthetics :)
>
> The Mercurial and Bazaar interfaces on the other hand, both seemed
> perfectly palatable (e.g. a bit more inclined to use words over arcane
> symbols), and Hg appears to be a clear winner against Bazaar when it
> comes to performance *right now*. So Guido's intuition actually sounds
> perfectly reasonable to me.



It's also about what the community prefers. Git was eliminated because it
didn't offer some stellar feature that  warranted forcing core developers to
use it when my little survey clearly showed it was the most disliked. Hg was
chosen (in my view) because the community wanted it; after I said Git was
out I had a lot of people come up to me stating their preference for
Mercurial. Once again, while Bazaar would have been fine, there was not
leaping out at me to cause me to think that I should potentially alienate
part of the community by going against their preference.

-Brett
___
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

Re: [Python-Dev] Test failures under Windows?

[Eric Smith]

Kristján Valur Jónsson wrote:

Btw, I am working on finding out the test suite failures for 
test_multiprocessing.


Some of those are caused by force builds on a branch, so make sure the 
errors are still occurring before you put too much effort into this. We 
made the branch before some recent fixes to the py3k branch.


But of course there may still be errors that exist.

Eric.

___
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

Re: [Python-Dev] [Python-ideas] CapPython's use of unbound methods

[Guido van Rossum]

[Adding back python-dev, I don't want this discussion fragmented.]

Denis,

I am arguing with Mark because he and others claim that it is possible
to add capabilities to Python *without* changing the flavor of the
language (much), and because he believes that using a subset of Python
is somehow helpful for Python programmers (or helps Python programmers
transitioning to CapPython). I'm trying to point out the limitations
of that approach.

In the past capability zealots have also requested forcefully that
Python should support capabilities natively. This sounds like an
unrealistic evolutionary path for the language, and I'm pointing that
out. (Certainly I don't see CapPython as a step in that direction --
perhaps Tav's approach could be.) If they are happy with a different
language that happens to resemble Python is some syntactic details
that would be fine of course, but then they shouldn't whine that Py3k
breaks their implementation.

I also suspect that Mark's approach might be easily crackable because
he doesn't know the CPython implementation well enough to be aware of
all possible attack vectors.

--Guido

On Tue, Mar 31, 2009 at 4:22 AM, spir  wrote:
> Le Mon, 30 Mar 2009 16:19:51 -0500,
> Guido van Rossum  s'exprima ainsi:
>
> [...]
>> > Fortunately CapPython does not have to make this kind of semantic
>> > change.
>>
>> Well of course it makes a much more severe semantic change by
>> declaring illegal all use of attribute names starting with underscore.
> [...]
>
> Hello,
>
> I wonder what's the meaning of this exchange. As I understand it, the point 
> of CapPython is precisely to build a different dialect which semantic field 
> is restricted, in order to comply with the so-called "Object-Capability" 
> security guidelines.
> We may like it or not. So what? I won't use CapPython, but I'm pleased to see 
> people do language experiments on a Python basis.
> Now, I also understand this: if ever for you CapPython breaks fondamental 
> design choices, then you may not like, as Python inventor, this projects to 
> be called *Python. I would even agree, from a moral point of view, with a 
> demand for a name change.
>
> (Sorry if this sounds a bit rude. Not sure of idiom connotations in english. 
> I prefere clarity to hypocrisy.)
>
> Denis
>
> PS: I had a kind of ProtoPython in mind. If ever someone comments that it's a 
> major semantic change; that it does not let pythonistas use their beloved 
> class-ic idioms; then I'll just laugh... Yes, it's even a major cognitive 
> change. This is precisely the intent. So what?
>
> --
> la vita e estrany
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] And the winner is...

[Terry Reedy]

Aahz wrote:

On Mon, Mar 30, 2009, Terry Reedy wrote:

Michael Urman wrote:

Guido:

We're switching to Mercurial (Hg).

And two hours later, GNOME announces their migration to git is
underway. I'd suspect a series of April Fools jokes, if it weren't two
days early. :)
Like Python, Gnome was/is using SVN and tested (at least) GIT, bzr, and  
hg mirrors, starting somewhat earlier than Python, for DVCS migration.  
As announced in January, the majority of *their* developers preferred  
GIT.  They started conversion then, in January, and made a progress  
announcement on March 19 (not yesterday).

http://permalink.gmane.org/gmane.comp.gnome.devel.announce/15

I fail to see any joke.  Different people have different tool preferences.


As Michael said, joke suspicion comes from the timing.


In private email, he explained that the py-dev announcement from Guido 
landed in his mailbox right next to a 'gnome-dev' request to cease 
commits until the GIT changeover was complete.  That coincidence, 
coupled with his personal git preference and not having closely followed 
the evaluating process of either group, lead to his reaction.  He also 
disavowed any intention to start a new bikeshed discussion.


Terry

___
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

Re: [Python-Dev] And the winner is...

[Mike Coleman]

On Mon, Mar 30, 2009 at 9:54 PM, Guido van Rossum  wrote:
> Yeah, I also think I'll just stop developing Python now and suggest
> that you all switch to Java, which has clearly won the mindshare war
> for languages. :-)

Heh.  :-)

Guess I should have said "mindshare among people whose technical
opinions I give weight to".  In that sense, Python mindshare seems to
have been and to still be increasing steadily.  (My Magic 8-ball says
"future unclear" for Java.)

The TIOBE index is entertaining, if you haven't seen it before:

http://www.tiobe.com/content/paperinfo/tpci/index.html


> But is his humility enough to cancel out Linus's attitude?

Why would I want to do that?  :-)


Seriously--thanks for all of your responses.  If it wasn't clear, I
was asking because I was curious about whether and why I should look
some more at hg.  I would never dream of trying to change anyone's
mind...

Mike
___
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

Re: [Python-Dev] And the winner is...

[Stephen J. Turnbull]

Nick Coghlan writes:

 > Every single git command line example I have seen gives me exactly the
 > same gut reaction I get whenever I have to read Perl code.

Every single one?  Sounds to me like the cause is probably something
you ate, not anything you read.  In the examples in the PEP, about 80%
of the commands were syntactically identical across VCSes.

I hope nobody is put off either git or bzr by the result of this PEP.
If there's anything striking about the PEP's examples, it's how
similar the usage of the VCSes would be in the context of Python's
workflow.  There are important differences, and I agree with Guido's
choice, for Python, on March 30, 2009.  But all three are capable
VCSes, with advantages and disadvantages, and were this PEP started
next June rather than last December, the result could have been very
different.
___
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

Re: [Python-Dev] And the winner is...

[Mike Coleman]

On Tue, Mar 31, 2009 at 12:31 AM, Stephen J. Turnbull
 wrote:
> I also just wrote a long post about the comparison of bzr to hg
> responding to a comment on baz...@canonical.com.  I won't recap it
> here but it might be of interest.

I found the post interesting.  Here's a link to the start of the thread:

https://lists.ubuntu.com/archives/bazaar/2009q1/055805.html

There's a bit of bafflement there regarding Python culture.  I can
relate--although I love Python, I don't feel like I understand the
culture either.

> It wouldn't be that hard to do a rewrite in Python, but the git
> programmers are mostly kernel people.  They write in C and shell.

I mentioned this once on the git list and Linus' response was
something like "C lets me see exactly what's going on".  I'm not
unsympathetic to this point of view--I'm really growing to loathe C++
partly because it *doesn't* let me see exactly what's going on--but
I'm not convinced, either.

It looks like there might be a Python clone sprouting here:

http://gitorious.org/projects/git-python/


> People who lean toward the DAG as *recording* history will prefer
> Mercurial or Bazaar. People who tend to see the DAG as a tool for
> *presenting* changes will prefer git.

I've noticed this tension as well.  It seems to me that both uses are
important, so I suspect all three will eventually steal each other's
features with respect to this over time.

Mike
___
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

[Python-Dev] 3.1a2

[Benjamin Peterson]

Hi,
I'd like to release the second alpha of 3.1 as planned on Saturday,
April 4th. There are currently two release blockers, issues #4847 and
#5470. #5470 appears to be Martin's issue.

I haven't looked at #4847 in depth, but appears that the csv module
will need some API changes to deal with encodings. Perhaps somebody
would like to sprint on it?

-- 
Regards,
Benjamin
___
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

[Python-Dev] Let's update CObject API so it is safe and regular!

[Larry Hastings]

The CObject API has two flaws.

First, there is no usable type safety mechanism.  You can store a void
*object, and a void *description.  There is no established schema for
the description; it could be an integer cast to a pointer, or it could
point to memory of any configuration, or it could be NULL.  Thus users
of the CObject API generally ignore it--thus working without any type
safety whatsoever.  A programmer could crash the interpreter from pure
Python by mixing and matching CObjects from different modules (e.g. give
"curses" a CObject from "_ctypes").

Second, the destructor callback is defined as taking *either* one *or*
two parameters, depending on whether the "descr" pointer is non-NULL. 
One can debate the finer points of what is and isn't defined behavior in

C, but at its heart this is a sloppy API.

MvL and I discussed this last night and decided to float a revision of
the API.  I wrote the patch, though, so don't blame Martin if you don't
like my specific approach.

The color of this particular bike shed is:
* The PyCObject is now a private data structure; you must use accessors.
 I added accessors for all the members.
* The constructors and the main accessor (PyCObject_AsVoidPtr) now all
 *require* a "const char *type" parameter, which must be a non-NULL C
 string of non-zero length.  If you call that accessor and the "type"
 is invalid *or doesn't match*, it fails.
* The destructor now takes the PyObject *, not the PyCObject *.  You
 must use accessors to get your hands on the data inside to free it.

Yes, you can easily skip around the "matching type" restriction by
calling PyCObject_AsVoidPtr(cobj, PyCObject_GetType(cobj)).  The point
of my API changes is to *encourage* correct use.

I've posted a patch implementing this change in the 3.1 trunk to the
bug tracker:

   http://bugs.python.org/issue5630

I look forward to your comments!


/larry/

___
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

Re: [Python-Dev] 3.1a2

[Hirokazu Yamamoto]

Benjamin Peterson wrote:

Hi,
I'd like to release the second alpha of 3.1 as planned on Saturday,
April 4th. There are currently two release blockers, issues #4847 and
#5470. #5470 appears to be Martin's issue.

I haven't looked at #4847 in depth, but appears that the csv module
will need some API changes to deal with encodings. Perhaps somebody
would like to sprint on it?



I added #5499 to release blocker because it needs specification 
decision. (It's too strong?)

___
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

[Python-Dev] regrtest behavior change

[R. David Murray]

At the sprint the developers decided that a long standing issue with
regrtest should be fixed: the fact that invalid imports in tests can
result in a test being skipped instead of producing an error.

I've just checked in a change to regrtest on the trunk.  It no longer
assumes that an ImportError means the test should be marked as skipped.
I have done my best to wrap all imports where errors _should_ cause
skips in the appropriate wrappers from test_support (import_module or
get_attribute).  Of course, since I can't run the tests on all possible
systems I may have missed some.  It's also possible that making this
change will unmask some errors that have been hidden by the previous
behavior, although I haven't found any instances of that so far.

Another issue is that there may be modules that don't exist on other VM
implementations where those modules would have been skipped on a test run
previous to this, and will now generate an ImportError.  We will happily
wrap imports for those modules when informed that such should be done.

I'll be watching the buildbots, but please let me know about any issues
that you find.  I'll be merging it to py3k as well, but there will be
no backport.

--
R. David Murray http://www.bitdance.com
___
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

[Python-Dev] This seems like a bug - main thread has None ident???

[skip]

Looking for some quick feedback on this.  I've bumped into what looks like a
bug in the threading module.  From the interpreter prompt:

>>> import threading
>>> threading.currentThread()
<_MainThread(MainThread, started)>
>>> print threading.currentThread().ident
None

The ident attribute is documented as being a number unless the thread has
yet to be started.  Shouldn't the main thread's ident attribute *always*
be non-None?  Clearly, it appears the main thread has been started.

Am I missing something obvious or have I hit a bug?  This is a fully updated
2.7a0 build, trunk:70878M.

Skip
___
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

Re: [Python-Dev] Test failures under Windows?

[David Bolen]

Kristján Valur Jónsson  writes:

> Btw, I am working on finding out the test suite failures for
> test_multiprocessing.

This is all well and good, but I still haven't seen any plausible
reason for not preventing these popups (in favor of stderr failures)
during buildbot test runs?  I don't get it - it just seems a no
brainer to help protect the Windows buildbots.  Surely there may be
similar issues down the road that also introduce the potential for
assertions?

I guess I'll stop asking after this note, but can anyone give a final
verdict on whether the older "-n" option can be restored to the
buildbot test.bat (from the revision history I'm not actually sure it
was intentionally removed in the first place)?  Unlike normal Windows
popups I can't protect against it easily through local modifications
to my build slave, since test.bat gets updated as part of the source
tree.

-- David

___
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

Re: [Python-Dev] This seems like a bug - main thread has None ident???

[skip]

skip> Am I missing something obvious or have I hit a bug?  This is a
skip> fully updated 2.7a0 build, trunk:70878M.

After noting that thread.get_ident() returned a thread id but that
threading.currentThread().ident was None I concluded that it is, in fact, a
bug in the threading module.  I opened a ticket:

http://bugs.python.org/issue5632

Skip
___
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

Re: [Python-Dev] Test failures under Windows?

[Jesse Noller]

On Tue, Mar 31, 2009 at 4:07 PM, David Bolen  wrote:
> Kristján Valur Jónsson  writes:
>
>> Btw, I am working on finding out the test suite failures for
>> test_multiprocessing.
>
> This is all well and good, but I still haven't seen any plausible
> reason for not preventing these popups (in favor of stderr failures)
> during buildbot test runs?  I don't get it - it just seems a no
> brainer to help protect the Windows buildbots.  Surely there may be
> similar issues down the road that also introduce the potential for
> assertions?
>
> I guess I'll stop asking after this note, but can anyone give a final
> verdict on whether the older "-n" option can be restored to the
> buildbot test.bat (from the revision history I'm not actually sure it
> was intentionally removed in the first place)?  Unlike normal Windows
> popups I can't protect against it easily through local modifications
> to my build slave, since test.bat gets updated as part of the source
> tree.
>
> -- David
>

I guess I missed the multiprocessing part of this discussion, but in
any case, see bug: http://bugs.python.org/issue5619 - once Martin and
I review it, it should be in trunk and elsewhere as needed.

-jesse
___
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

Re: [Python-Dev] Test failures under Windows?

[Jesse Noller]

2009/3/31 Kristján Valur Jónsson :
> Right, my question to microsoft was more about making sure that a 
> __crtMessageBox() actually does nothing, when running unattended as a service.
>
> Also, we should be seeing the same problem in non-debug versions, since the 
> _set_invalid_parameter_handler() is no longer called, and the default one 
> also puts up a message box.  The Assertion is then performed _in_addition_ on 
> debug builds:
> >From 
> >ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/c0e67934-1a41-4016-ad8e-972828f3ac11.htm
> In the following example, an invalid parameter error handler is used to print 
> the function that received the invalid parameter and the file and line in CRT 
> sources. When the debug CRT library is used, invalid parameter errors also 
> throw an assertion, which is disabled in this example using _CrtSetReportMode.
>
> Btw, I am working on finding out the test suite failures for 
> test_multiprocessing.
> K

I spoke to Martin about this yesterday, apparently a specific test in
the multiprocessing suite was triggering these dialogs (the test
invalid handle test). We're working on a patch for multiprocessing so
that the children will obey the flag

-jesse
___
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

Re: [Python-Dev] Broken import?

[Nick Coghlan]

Terry Reedy wrote:
> Terry Reedy wrote:
>> Guido van Rossum wrote:
> 
 The reason seems to be that until the outermost import (in this case
 p.b) is completed, while sys.modules has the (incomplete) modules 'p',
 'p.a' and 'p.b', the attributes p.a and p.b aren't added until after
 their import is completed. Which it isn't during recursive import.
 Apparently 'from  import ' looks for the
  attribute in the  object. This is because
 "from...import" can also be used to import objects other than modules
 (e.g. "from M import C"). I'm guessing that setting the attribute is
 delayed until the import is totally complete, because upon a failed
 import we remove the half-imported module object from sys.modules, but
 apparently we didn 't want to be in the business of removing the
 attribute from the parent package, so that's only set after the import
 is deemed successful.
> 
> I remember a pydev discussion on this point.

A half-baked idea that I just posted to the tracker item:

What if the import semantics were adjusted so that, as a last gasp
effort before bailing out with an ImportError, the import process
checked sys.modules again with the full module name?

Would that be enough to eliminate this error?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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

Re: [Python-Dev] Test failures under Windows?

[Kristján Valur Jónsson]

I found a different problem in multiprocessing, for the py3k.
In import.c, get_file.c, it was knowingly leaking FILE objects, while the 
underlying fh was being correctly closed.  This caused the CRT to assert when 
cleaning up FILE pointers on subprocess exit.
I fixed this this afternoon in a submission to the py3k branch.

K

-Original Message-
From: Jesse Noller [mailto:jnol...@gmail.com] 
Sent: 31. mars 2009 21:31
To: Kristján Valur Jónsson
Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen; 
python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows?

2009/3/31 Kristján Valur Jónsson :
> Right, my question to microsoft was more about making sure that a 
> __crtMessageBox() actually does nothing, when running unattended as a service.
>
> Also, we should be seeing the same problem in non-debug versions, since the 
> _set_invalid_parameter_handler() is no longer called, and the default one 
> also puts up a message box.  The Assertion is then performed _in_addition_ on 
> debug builds:
> >From 
> >ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/c0e67934-1a41-4016-ad8e-972828f3ac11.htm
> In the following example, an invalid parameter error handler is used to print 
> the function that received the invalid parameter and the file and line in CRT 
> sources. When the debug CRT library is used, invalid parameter errors also 
> throw an assertion, which is disabled in this example using _CrtSetReportMode.
>
> Btw, I am working on finding out the test suite failures for 
> test_multiprocessing.
> K

I spoke to Martin about this yesterday, apparently a specific test in
the multiprocessing suite was triggering these dialogs (the test
invalid handle test). We're working on a patch for multiprocessing so
that the children will obey the flag

-jesse

___
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

Re: [Python-Dev] Test failures under Windows?

[Jesse Noller]

Does it need to be backported? I wonder when that was introduced.
Also, what CL was it so I can review it?

2009/3/31 Kristján Valur Jónsson :
> I found a different problem in multiprocessing, for the py3k.
> In import.c, get_file.c, it was knowingly leaking FILE objects, while the 
> underlying fh was being correctly closed.  This caused the CRT to assert when 
> cleaning up FILE pointers on subprocess exit.
> I fixed this this afternoon in a submission to the py3k branch.
>
> K
>
> -Original Message-
> From: Jesse Noller [mailto:jnol...@gmail.com]
> Sent: 31. mars 2009 21:31
> To: Kristján Valur Jónsson
> Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen; 
> python-dev@python.org
> Subject: Re: [Python-Dev] Test failures under Windows?
>
> 2009/3/31 Kristján Valur Jónsson :
>> Right, my question to microsoft was more about making sure that a 
>> __crtMessageBox() actually does nothing, when running unattended as a 
>> service.
>>
>> Also, we should be seeing the same problem in non-debug versions, since the 
>> _set_invalid_parameter_handler() is no longer called, and the default one 
>> also puts up a message box.  The Assertion is then performed _in_addition_ 
>> on debug builds:
>> >From 
>> >ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/c0e67934-1a41-4016-ad8e-972828f3ac11.htm
>> In the following example, an invalid parameter error handler is used to 
>> print the function that received the invalid parameter and the file and line 
>> in CRT sources. When the debug CRT library is used, invalid parameter errors 
>> also throw an assertion, which is disabled in this example using 
>> _CrtSetReportMode.
>>
>> Btw, I am working on finding out the test suite failures for 
>> test_multiprocessing.
>> K
>
> I spoke to Martin about this yesterday, apparently a specific test in
> the multiprocessing suite was triggering these dialogs (the test
> invalid handle test). We're working on a patch for multiprocessing so
> that the children will obey the flag
>
> -jesse
>
>
___
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

Re: [Python-Dev] And the winner is...

[Nick Coghlan]

Stephen J. Turnbull wrote:
> Nick Coghlan writes:
> 
>  > Every single git command line example I have seen gives me exactly the
>  > same gut reaction I get whenever I have to read Perl code.
> 
> Every single one?  Sounds to me like the cause is probably something
> you ate, not anything you read.  In the examples in the PEP, about 80%
> of the commands were syntactically identical across VCSes.

What, hyperbole on the internets? ;)

The non-trivial examples are the ones I was talking about - as you say,
for trivial tasks, the only difference is typically going to be in the
exact name of the command.

> I hope nobody is put off either git or bzr by the result of this PEP.
> If there's anything striking about the PEP's examples, it's how
> similar the usage of the VCSes would be in the context of Python's
> workflow.  There are important differences, and I agree with Guido's
> choice, for Python, on March 30, 2009.  But all three are capable
> VCSes, with advantages and disadvantages, and were this PEP started
> next June rather than last December, the result could have been very
> different.

Indeed! (although I doubt git's CLI will ever evolve into anything I
could claim to love)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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

Re: [Python-Dev] And the winner is...

[Eduardo O. Padoan]

On Tue, Mar 31, 2009 at 3:04 PM, Mike Coleman  wrote:
> It looks like there might be a Python clone sprouting here:
>
>    http://gitorious.org/projects/git-python/

AFAIK, git-python is just a lib to manipulate git repos from python,
not a git clone. Dulwich is more like it:

http://samba.org/~jelmer/dulwich/


-- 
Eduardo de Oliveira Padoan
http://importskynet.blogspot.com
http://djangopeople.net/edcrypt/

"Distrust those in whom the desire to punish is strong."
   -- Goethe, Nietzsche, Dostoevsky
___
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

Re: [Python-Dev] Test failures under Windows?

[Martin v. Löwis]

I guess I'll stop asking after this note, but can anyone give a final
verdict on whether the older "-n" option can be restored to the
buildbot test.bat (from the revision history I'm not actually sure it
was intentionally removed in the first place)? 


I have now restored it; it was removed by an unintentional merge
from the trunk.

Notice, however, that the feature was never present in the trunk.

Regards,
Martin
___
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

Re: [Python-Dev] Broken import?

[Greg Ewing]

Nick Coghlan wrote:


Jim Fulton's example in that tracker issue shows that with a bit of
creativity you can provoke this behaviour *without* using a from-style
import. Torsten Bronger later brought up the same issue that Fredrik did
- it prevents some kinds of explicit relative import that look like they
should be fine.


I haven't been following this very closely, but if there's
something that's making absolute and relative imports
behave differently, I think it should be fixed. The only
difference between an absolute and relative import of the
same module should be the way you specify the module.

--
Greg

___
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

Re: [Python-Dev] Test failures under Windows?

[Kristján Valur Jónsson]

Revision 70843.
I don't know when this crept in.  I didn't go and check if it applies to other 
branches too.

Also, I'm sorry for just checking this in witout warning.  But I had just spent 
what amounts to a full day tracking this down which was tricky because it 
happens in a subprocess and those are hard to debug on windows.  My eagerness 
got the best of me.

But again, it shows how useful assertions can be and why we ought not to 
disable them.

Cheers, 
Kristján
-Original Message-
From: Jesse Noller [mailto:jnol...@gmail.com] 
Sent: 31. mars 2009 22:00
To: Kristján Valur Jónsson
Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen; 
python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows?

Does it need to be backported? I wonder when that was introduced.
Also, what CL was it so I can review it?

2009/3/31 Kristján Valur Jónsson :
> I found a different problem in multiprocessing, for the py3k.
> In import.c, get_file.c, it was knowingly leaking FILE objects, while the 
> underlying fh was being correctly closed.  This caused the CRT to assert when 
> cleaning up FILE pointers on subprocess exit.
> I fixed this this afternoon in a submission to the py3k branch.
>
> K

___
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

Re: [Python-Dev] And the winner is...

[Greg Ewing]

Mike Coleman wrote:


I mentioned this once on the git list and Linus' response was
something like "C lets me see exactly what's going on".  I'm not
unsympathetic to this point of view--I'm really growing to loathe C++
partly because it *doesn't* let me see exactly what's going on--but
I'm not convinced, either.


I think Python lets you see exactly what's going on
too, at the level of abstraction you're working with.

The problem with C++ is that it indiscriminately mixes
up wildly different levels of abstraction, so that it's
hard to look at a piece of code and decide whether it's
doing something high-level or low-level.

Python takes a uniformly high-level view of everything,
which is fine for the vast majority of application
programming, I think -- VCSes included.

--
Greg
___
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

Re: [Python-Dev] And the winner is...

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephen J. Turnbull wrote:

> I also just wrote a long post about the comparison of bzr to hg
> responding to a comment on baz...@canonical.com.  I won't recap it
> here but it might be of interest.

Thank you very much for your writeups on that thread:  both in tone and
in content I found them extremely helpful.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ0riB+gerLs4ltQ4RAir2AJ4rXedI4gfkaZxP5LRiOSonAI/csQCgqkpb
CY6QHmE8VHpGYGaENeUMnXQ=
=t/1R
-END PGP SIGNATURE-

___
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

Re: [Python-Dev] Test failures under Windows?

[David Bolen]

"Martin v. Löwis"  writes:

> Notice, however, that the feature was never present in the trunk.

Yep - would be nice if it were to get backported to trunk at some
point but that's a separate discussion ... presumably at some point
py3k will be the trunk anyway, and for better or worst (perhaps due to
the sorts of changes made) the assertions seem to have hit the py3k
branch more than others.

Thanks for the test.bat change.

-- David

___
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

Re: [Python-Dev] Test failures under Windows?

[David Bolen]

Kristján Valur Jónsson  writes:

> But again, it shows how useful assertions can be and why we ought
> not to disable them.

Note that just to be clear, I'm certainly not advocating the disabling
of CRT assertions - just the redirection of them so they don't prevent
unattended test runs from completing.

-- David

___
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

Re: [Python-Dev] And the winner is...

[Alex Martelli]

On Tue, Mar 31, 2009 at 5:42 PM, Tres Seaver  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Stephen J. Turnbull wrote:
>
> > I also just wrote a long post about the comparison of bzr to hg
> > responding to a comment on baz...@canonical.com.  I won't recap it
> > here but it might be of interest.
>
> Thank you very much for your writeups on that thread:  both in tone and
> in content I found them extremely helpful.


I'd like to read that thread for my edification -- might there be a URL for
it perhaps...?

Thanks,

Alex
___
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

Re: [Python-Dev] And the winner is...

[Alex Martelli]

On Tue, Mar 31, 2009 at 5:42 PM, Tres Seaver  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Stephen J. Turnbull wrote:
>
> > I also just wrote a long post about the comparison of bzr to hg
> > responding to a comment on baz...@canonical.com.  I won't recap it
> > here but it might be of interest.
>
> Thank you very much for your writeups on that thread:  both in tone and
> in content I found them extremely helpful.


I'd like to read that thread for my edification -- might there be a URL for
it perhaps...?

Thanks,

Alex
___
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

Re: [Python-Dev] And the winner is...

[Alexandre Vassalotti]

2009/3/31 Alex Martelli :
> On Tue, Mar 31, 2009 at 5:42 PM, Tres Seaver  wrote:
>> Stephen J. Turnbull wrote:
>>
>> > I also just wrote a long post about the comparison of bzr to hg
>> > responding to a comment on baz...@canonical.com.  I won't recap it
>> > here but it might be of interest.
>>
>> Thank you very much for your writeups on that thread:  both in tone and
>> in content I found them extremely helpful.
>
> I'd like to read that thread for my edification -- might there be a URL for
> it perhaps...?
>

https://lists.ubuntu.com/archives/bazaar/2009q1/055850.html
https://lists.ubuntu.com/archives/bazaar/2009q1/055872.html

-- Alexandre
___
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

Re: [Python-Dev] And the winner is...

[Alex Martelli]

On Tue, Mar 31, 2009 at 6:33 PM, Alexandre Vassalotti  wrote:
   ...

> html 
> https://lists.ubuntu.com/archives/bazaar/2009q1/055872.html
>

Perfect, thanks!

Alex
___
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

Re: [Python-Dev] And the winner is...

[Alex Martelli]

On Tue, Mar 31, 2009 at 6:33 PM, Alexandre Vassalotti  wrote:
   ...

> html 
> https://lists.ubuntu.com/archives/bazaar/2009q1/055872.html
>

Perfect, thanks!

Alex
___
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

[Python-Dev] issue5578 - explanation

[Maciej Fijalkowski]

So. The issue was closed and I suppose it was closed by not entirely
understanding
the problem (or I didn't get it completely).

The question is - what the following code should do?

def f():
  a = 2
  class C:
exec 'a = 42'
abc = a
  return C

print f().abc

(quick answer - on python2.5 it return 42, on python 2.6 and up it
returns 2, the patch changes
it to syntax error).

I would say that returning 2 is the less obvious thing to do. The
reason why IMO this should
be a syntax error is this code:

def f():
  a = 2
  def g():
exec 'a = 42'
abc = a

which throws syntax error.

Cheers,
fijal
___
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

Re: [Python-Dev] issue5578 - explanation

[Guido van Rossum]

Well hold on for a minute, I remember we used to have an exec
statement in a class body in the standard library, to define some file
methods in socket.py IIRC.  It's a totally different case than exec in
a nested function, and I don't believe it should be turned into a
syntax error at all. An exec in a class body is probably meant to
define some methods or other class attributes. I actually think the
2.5 behavior is correct, and I don't know why it changed in 2.6.

--Guido

On Tue, Mar 31, 2009 at 8:15 PM, Maciej Fijalkowski  wrote:
> So. The issue was closed and I suppose it was closed by not entirely
> understanding
> the problem (or I didn't get it completely).
>
> The question is - what the following code should do?
>
> def f():
>  a = 2
>  class C:
>    exec 'a = 42'
>    abc = a
>  return C
>
> print f().abc
>
> (quick answer - on python2.5 it return 42, on python 2.6 and up it
> returns 2, the patch changes
> it to syntax error).
>
> I would say that returning 2 is the less obvious thing to do. The
> reason why IMO this should
> be a syntax error is this code:
>
> def f():
>  a = 2
>  def g():
>    exec 'a = 42'
>    abc = a
>
> which throws syntax error.
>
> Cheers,
> fijal
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

[Guido van Rossum]

Can you get Jim Fulton's feedback? ISTR he originated this.

On Tue, Mar 31, 2009 at 12:14 PM, Larry Hastings  wrote:
>
> The CObject API has two flaws.
>
> First, there is no usable type safety mechanism.  You can store a void
> *object, and a void *description.  There is no established schema for
> the description; it could be an integer cast to a pointer, or it could
> point to memory of any configuration, or it could be NULL.  Thus users
> of the CObject API generally ignore it--thus working without any type
> safety whatsoever.  A programmer could crash the interpreter from pure
> Python by mixing and matching CObjects from different modules (e.g. give
> "curses" a CObject from "_ctypes").
>
> Second, the destructor callback is defined as taking *either* one *or*
> two parameters, depending on whether the "descr" pointer is non-NULL. One
> can debate the finer points of what is and isn't defined behavior in
> C, but at its heart this is a sloppy API.
>
> MvL and I discussed this last night and decided to float a revision of
> the API.  I wrote the patch, though, so don't blame Martin if you don't
> like my specific approach.
>
> The color of this particular bike shed is:
> * The PyCObject is now a private data structure; you must use accessors.
>  I added accessors for all the members.
> * The constructors and the main accessor (PyCObject_AsVoidPtr) now all
>  *require* a "const char *type" parameter, which must be a non-NULL C
>  string of non-zero length.  If you call that accessor and the "type"
>  is invalid *or doesn't match*, it fails.
> * The destructor now takes the PyObject *, not the PyCObject *.  You
>  must use accessors to get your hands on the data inside to free it.
>
> Yes, you can easily skip around the "matching type" restriction by
> calling PyCObject_AsVoidPtr(cobj, PyCObject_GetType(cobj)).  The point
> of my API changes is to *encourage* correct use.
>
> I've posted a patch implementing this change in the 3.1 trunk to the
> bug tracker:
>
>   http://bugs.python.org/issue5630
>
> I look forward to your comments!
>
>
> /larry/
>
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] issue5578 - explanation

[Maciej Fijalkowski]

Because classes have now it's own local scope (according to Martin)

It's not about exec in class, it's about exec in class in nested function.

On Wed, Apr 1, 2009 at 5:25 AM, Guido van Rossum  wrote:
> Well hold on for a minute, I remember we used to have an exec
> statement in a class body in the standard library, to define some file
> methods in socket.py IIRC.  It's a totally different case than exec in
> a nested function, and I don't believe it should be turned into a
> syntax error at all. An exec in a class body is probably meant to
> define some methods or other class attributes. I actually think the
> 2.5 behavior is correct, and I don't know why it changed in 2.6.
>
> --Guido
>
> On Tue, Mar 31, 2009 at 8:15 PM, Maciej Fijalkowski  wrote:
>> So. The issue was closed and I suppose it was closed by not entirely
>> understanding
>> the problem (or I didn't get it completely).
>>
>> The question is - what the following code should do?
>>
>> def f():
>>  a = 2
>>  class C:
>>    exec 'a = 42'
>>    abc = a
>>  return C
>>
>> print f().abc
>>
>> (quick answer - on python2.5 it return 42, on python 2.6 and up it
>> returns 2, the patch changes
>> it to syntax error).
>>
>> I would say that returning 2 is the less obvious thing to do. The
>> reason why IMO this should
>> be a syntax error is this code:
>>
>> def f():
>>  a = 2
>>  def g():
>>    exec 'a = 42'
>>    abc = a
>>
>> which throws syntax error.
>>
>> Cheers,
>> fijal
>> ___
>> 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/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
___
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

Re: [Python-Dev] issue5578 - explanation

[Guido van Rossum]

OK that might change matters. Shame on you though for posting a patch
without any explanation of the issue.

On Tue, Mar 31, 2009 at 8:36 PM, Maciej Fijalkowski  wrote:
> Because classes have now it's own local scope (according to Martin)
>
> It's not about exec in class, it's about exec in class in nested function.
>
> On Wed, Apr 1, 2009 at 5:25 AM, Guido van Rossum  wrote:
>> Well hold on for a minute, I remember we used to have an exec
>> statement in a class body in the standard library, to define some file
>> methods in socket.py IIRC.  It's a totally different case than exec in
>> a nested function, and I don't believe it should be turned into a
>> syntax error at all. An exec in a class body is probably meant to
>> define some methods or other class attributes. I actually think the
>> 2.5 behavior is correct, and I don't know why it changed in 2.6.
>>
>> --Guido
>>
>> On Tue, Mar 31, 2009 at 8:15 PM, Maciej Fijalkowski  wrote:
>>> So. The issue was closed and I suppose it was closed by not entirely
>>> understanding
>>> the problem (or I didn't get it completely).
>>>
>>> The question is - what the following code should do?
>>>
>>> def f():
>>>  a = 2
>>>  class C:
>>>    exec 'a = 42'
>>>    abc = a
>>>  return C
>>>
>>> print f().abc
>>>
>>> (quick answer - on python2.5 it return 42, on python 2.6 and up it
>>> returns 2, the patch changes
>>> it to syntax error).
>>>
>>> I would say that returning 2 is the less obvious thing to do. The
>>> reason why IMO this should
>>> be a syntax error is this code:
>>>
>>> def f():
>>>  a = 2
>>>  def g():
>>>    exec 'a = 42'
>>>    abc = a
>>>
>>> which throws syntax error.
>>>
>>> Cheers,
>>> fijal
>>> ___
>>> 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/guido%40python.org
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] issue5578 - explanation

[Maciej Fijalkowski]

Shame on me indeed.

On Wed, Apr 1, 2009 at 5:38 AM, Guido van Rossum  wrote:
> OK that might change matters. Shame on you though for posting a patch
> without any explanation of the issue.
>
> On Tue, Mar 31, 2009 at 8:36 PM, Maciej Fijalkowski  wrote:
>> Because classes have now it's own local scope (according to Martin)
>>
>> It's not about exec in class, it's about exec in class in nested function.
>>
>> On Wed, Apr 1, 2009 at 5:25 AM, Guido van Rossum  wrote:
>>> Well hold on for a minute, I remember we used to have an exec
>>> statement in a class body in the standard library, to define some file
>>> methods in socket.py IIRC.  It's a totally different case than exec in
>>> a nested function, and I don't believe it should be turned into a
>>> syntax error at all. An exec in a class body is probably meant to
>>> define some methods or other class attributes. I actually think the
>>> 2.5 behavior is correct, and I don't know why it changed in 2.6.
>>>
>>> --Guido
>>>
>>> On Tue, Mar 31, 2009 at 8:15 PM, Maciej Fijalkowski  
>>> wrote:
 So. The issue was closed and I suppose it was closed by not entirely
 understanding
 the problem (or I didn't get it completely).

 The question is - what the following code should do?

 def f():
  a = 2
  class C:
    exec 'a = 42'
    abc = a
  return C

 print f().abc

 (quick answer - on python2.5 it return 42, on python 2.6 and up it
 returns 2, the patch changes
 it to syntax error).

 I would say that returning 2 is the less obvious thing to do. The
 reason why IMO this should
 be a syntax error is this code:

 def f():
  a = 2
  def g():
    exec 'a = 42'
    abc = a

 which throws syntax error.

 Cheers,
 fijal
 ___
 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/guido%40python.org

>>>
>>>
>>>
>>> --
>>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>>>
>>
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
___
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

Re: [Python-Dev] 3.1a2

[R. David Murray]

On Tue, 31 Mar 2009 at 14:09, Benjamin Peterson wrote:

I haven't looked at #4847 in depth, but appears that the csv module
will need some API changes to deal with encodings. Perhaps somebody
would like to sprint on it?


First we have to figure out what should be done.

http://bugs.python.org/4847

Having read through the ticket, it seems that a CSV file must be (and
2.6 was) treated as a binary file, and part of the CSV module's job
is to convert that binary data to and from strings.  That is, the CSV
module is at the same layer of the input stack as the TextIOWrapper.
So IMO it should have an encoding parameter, and the defaults should be
handled the same way they are for TextIOBase.

_csv as indicated by the initial error report is in py3k expecting to read
strings from the iterator passed to it, which IMO is wrong.  It should
be expecting bytes.  The problem with this solution is that those people
currently passing it string iterators would have to change their code.

The documentation says "If csvfile is a file object, it must be opened
with the ???b??? flag on platforms where that makes a difference."
With the advent of unicode strings, it now makes a difference on all
platforms.

--
R. David Murray http://www.bitdance.com___
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