Re: [Python-Dev] __file__

On approximately 2/26/2010 8:31 PM, came the following characters from the keyboard of Brett Cannon: I'm not sure why what you did is different than what I did, -M uses runpy which is not directly equivalent to importing. OK, that gives me some good keywords for searching documentation.

Re: [Python-Dev] __file__

On Fri, Feb 26, 2010 at 5:13 PM, Brett Cannon wrote: > On Fri, Feb 26, 2010 at 15:35, Glenn Linderman >> When a .pyc is renamed to .py, Python (3.1 at least) recognizes and uses >> it... I assume by design, rather than accident, but I don't know the >> history. > > This does not work for me (nor

Re: [Python-Dev] __file__

On Fri, Feb 26, 2010 at 20:08, Glenn Linderman > wrote: > On approximately 2/26/2010 5:13 PM, came the following characters from the > keyboard of Brett Cannon: > > On Fri, Feb 26, 2010 at 15:35, Glenn Linderman > > v%2bpyt...@g.nevcal.com >> wrote: >> >>On approximately 2/26/2010 2:55 PM,

Re: [Python-Dev] __file__

On approximately 2/26/2010 5:13 PM, came the following characters from the keyboard of Brett Cannon: On Fri, Feb 26, 2010 at 15:35, Glenn Linderman > wrote: On approximately 2/26/2010 2:55 PM, came the following characters from the keyboard of Brett Cannon

Re: [Python-Dev] __file__

Barry Warsaw wrote: On Feb 26, 2010, at 02:09 PM, Brett Cannon wrote: But a benefit of no longer supporting bytecode-only modules by default is it cuts back on possible stat calls which slows down Python's startup time (a complaint I hear a lot). Performance issues become even more acute if yo

Re: [Python-Dev] __file__

On Feb 26, 2010, at 8:30 PM, Brett Cannon wrote: So what is the burden of including a single source file that added the support to load from bytecode-only modules? I am not saying you shouldn't be able to have this functionality, just that I personally don't want to pay for the overhead (b

Re: [Python-Dev] Another version of Python

On Sat, 27 Feb 2010 04:53:36 am Michael Foord wrote: > On 26/02/2010 17:26, s...@pobox.com wrote: > > >> Â Â http://www.staringispolite.com/likepython/ > > > > Simon> I'm reminded of LOLPython:. > > > > You know, I'm thinking while both are obviously tongue-in-chee

Re: [Python-Dev] __file__

On Fri, Feb 26, 2010 at 17:20, Doug Hellmann wrote: > > On Feb 26, 2010, at 5:59 PM, Michael Foord wrote: > > On 26/02/2010 22:09, Brett Cannon wrote: > > > > On Thu, Feb 25, 2010 at 16:13, Greg Ewing wrote: > >> Michael Foord wrote: >> >> I thought we agreed at the language summit that if a .py

Re: [Python-Dev] __file__

On Sat, 27 Feb 2010 09:09:26 am Brett Cannon wrote: > I think it's almost a dis-service to support bytecode-only > files as it leads people who are misinformed or simply don't take the > time to understand what is contained in a .pyc file into a false > sense of security about their code not being

Re: [Python-Dev] __file__

On Feb 26, 2010, at 5:59 PM, Michael Foord wrote: On 26/02/2010 22:09, Brett Cannon wrote: On Thu, Feb 25, 2010 at 16:13, Greg Ewing > wrote: Michael Foord wrote: I thought we agreed at the language summit that if a .pyc was in the place of the source file it *could* be imported from -

Re: [Python-Dev] __file__

On Fri, Feb 26, 2010 at 15:35, Glenn Linderman > wrote: > On approximately 2/26/2010 2:55 PM, came the following characters from the > keyboard of Brett Cannon: > > >>Maybe Greg's and my response to the mention of dropping this feature >>is too strong -- after all we're both dinosaurs. An

Re: [Python-Dev] __file__

On Fri, Feb 26, 2010 at 4:58 PM, Ian Bicking wrote: > The one issue I thought would be resolved by not easily allowing > .pyc-only distributions is the case when you rename a file (say > module.py to newmodule.py) and there is a module.pyc laying around, > and you don't get the ImportError you wou

Re: [Python-Dev] __file__

On Fri, Feb 26, 2010 at 16:58, Ian Bicking wrote: > The one issue I thought would be resolved by not easily allowing > .pyc-only distributions is the case when you rename a file (say > module.py to newmodule.py) and there is a module.pyc laying around, > and you don't get the ImportError you woul

Re: [Python-Dev] __file__

The one issue I thought would be resolved by not easily allowing .pyc-only distributions is the case when you rename a file (say module.py to newmodule.py) and there is a module.pyc laying around, and you don't get the ImportError you would expect from "import module" -- and to make it worse everyt

Re: [Python-Dev] __file__

On 26/02/2010 23:35, Glenn Linderman wrote: On approximately 2/26/2010 2:55 PM, came the following characters from the keyboard of Brett Cannon: Maybe Greg's and my response to the mention of dropping this feature is too strong -- after all we're both dinosaurs. And maybe the developers who wan

Re: [Python-Dev] __file__

On approximately 2/26/2010 2:55 PM, came the following characters from the keyboard of Brett Cannon: Maybe Greg's and my response to the mention of dropping this feature is too strong -- after all we're both dinosaurs. And maybe the developers who want the feature can write their own

[Python-Dev] Python 2.6.5 rc 1

Hello everybody! I hope you all had as great a time at Pycon 2010 as I did. No time to begin recovering though, we're on to Python 2.6.5 rc 1, which I would like to release on Monday. We have one showstopper still open, and I'll try to respond to that asap. http://bugs.python.org/issue7250

Re: [Python-Dev] __file__

On 26/02/2010 22:09, Brett Cannon wrote: On Thu, Feb 25, 2010 at 16:13, Greg Ewing > wrote: Michael Foord wrote: I thought we agreed at the language summit that if a .pyc was in the place of the source file it *could* be imported from -

Re: [Python-Dev] __file__

On Fri, Feb 26, 2010 at 14:29, Guido van Rossum wrote: > On Fri, Feb 26, 2010 at 2:09 PM, Brett Cannon wrote: > > And personally, I don't see what bytecode-only modules buy you. The > > obfuscation argument is bunk as we all know. Bytecode contains so much > data > > that disassembling it gives

Re: [Python-Dev] __file__

On Feb 26, 2010, at 02:09 PM, Brett Cannon wrote: >But a benefit of no longer supporting bytecode-only modules by default is it >cuts back on possible stat calls which slows down Python's startup time (a >complaint I hear a lot). Performance issues become even more acute if you try >to come up wit

Re: [Python-Dev] __file__

On Fri, Feb 26, 2010 at 2:09 PM, Brett Cannon wrote: > And personally, I don't see what bytecode-only modules buy you. The > obfuscation argument is bunk as we all know. Bytecode contains so much data > that disassembling it gives you a very clear picture of what the original > code was like. I th

Re: [Python-Dev] The fate of Distutils in Python 2.7

On Fri, Feb 26, 2010 at 11:13 PM, Brett Cannon wrote: [..] > I assume you want the Distutils2 component to auto-assign to you like > Distutils currently does? If so I can add the component for you if people > don't object to the new component. Sounds good -- Thanks ___

Re: [Python-Dev] The fate of Distutils in Python 2.7

On Fri, Feb 26, 2010 at 13:44, Tarek Ziadé wrote: > Hello, > > This is a follow-up of the Pycon summit + sprints on packaging. > > This is what we have planned to do: > > 1. refactor distutils in a new standalone version called distutils2 > [this is done already and we are actively working in the

Re: [Python-Dev] __file__

On Thu, Feb 25, 2010 at 16:13, Greg Ewing wrote: > Michael Foord wrote: > > I thought we agreed at the language summit that if a .pyc was in the place >> of the source file it *could* be imported from - making pyc only >> distributions possible. >> > > Ah, that's okay, then. Sorry about the panic

Re: [Python-Dev] PEP 3188: Implementation Questions

Meador Inge wrote: 3. Using Decimal keeps the desired precision, Well, sort of, but then you end up doing arithmetic in decimal instead of binary, which could give different results. Maybe the solution is to give ctypes long double objects the ability to do arithmetic? -- Greg __

[Python-Dev] The fate of Distutils in Python 2.7

Hello, This is a follow-up of the Pycon summit + sprints on packaging. This is what we have planned to do: 1. refactor distutils in a new standalone version called distutils2 [this is done already and we are actively working in the code] 2. completely revert distutils in Lib/ and Doc/ so the cod

Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)

On Fri, Feb 26, 2010 at 3:59 PM, Lennart Regebro wrote: > I'm worrying that adding such a > thing to stdlib will do so in an unfinished state, and we'll just en > up with yet another state of semi-brokenness. I valid worry, and compelling. As I've alluded to before, leaving it out and allowing a

Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)

On Fri, Feb 19, 2010 at 19:37, wrote: > >    Lennart> I would like if we could look into making a timezone module >    Lennart> that works on Python 2.5 to 3.2 that uses system data... > > 2.5, 2.6 and 3.1 are completely off the radar screen at this point.  The > best you could hope for is that s

Re: [Python-Dev] Another version of Python

On Fri, Feb 26, 2010 at 12:53 PM, Michael Foord wrote: > On 26/02/2010 17:26, s...@pobox.com wrote: >> >>     >>  Â  Â http://www.staringispolite.com/likepython/ >> >>     Simon>  I'm reminded of LOLPython:. >> >> You know, I'm thinking while both are obviously tongue-in-cheek

Re: [Python-Dev] Another version of Python

On 26/02/2010 17:26, s...@pobox.com wrote: >> Â Â http://www.staringispolite.com/likepython/ Simon> I'm reminded of LOLPython:. You know, I'm thinking while both are obviously tongue-in-cheek we should probably include them on the /dev/implementations page of p

Re: [Python-Dev] Another version of Python

>>    http://www.staringispolite.com/likepython/ Simon> I'm reminded of LOLPython: . You know, I'm thinking while both are obviously tongue-in-cheek we should probably include them on the /dev/implementations page of python.org, probably in a separate section at th

[Python-Dev] Pickling named tuples on IronPython

Hello Raymond, Named tuples have compatibility code to enable them to work on IronPython without frame support, but unfortunately this doesn't allow pickling / unpickling of named tuples. One fix is to manually set __module__ on the named tuples once created, but I wonder if it would be poss

Re: [Python-Dev] Another version of Python

2010/2/24 skip : > Some of you have probably already seen this, but in case you haven't: > >    http://www.staringispolite.com/likepython/ > > :-) I'm reminded of LOLPython: . -- Cheers, Simon B. ___ Python-Dev mailing list Python-

Re: [Python-Dev] contributor to committer

Hello, > > +1 > Thanks all, for your warm welcome. > > The usual caveats apply though: > - don't get carried away with the privileges > - even core devs still put patches on the tracker sometimes > - if in doubt, ask for advice on python-dev (or IRC) > - make sure to su