Re: [Python-Dev] runpy.py
Benjamin Peterson wrote: 2009/8/24 Chris Withers : Guido van Rossum wrote: Anyway it looks like if someone wants to try this, only the code in runpy.py needs to be touched. Where is runpy.py to be found? $ find . -name "runpy.py" ./Lib/runpy.py Heh, grep beats Mk I eyeball ;-) (I did actually look in Lib...) Anyway, so how is the stuff in runpy.py wired up to the command line options passed to the interpretter? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runpy.py
2009/8/25 Chris Withers : > Anyway, so how is the stuff in runpy.py wired up to the command line options > passed to the interpretter? Modules/main.c -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runpy.py
Benjamin Peterson wrote: > 2009/8/25 Chris Withers : > >> Anyway, so how is the stuff in runpy.py wired up to the command line options >> passed to the interpretter? > > Modules/main.c The most relevant functions in there are "RunMainFromImporter()" (attempting zipfile/directory execution) and "RunModule()" (-m switch and also called for zipfile/directory execution). The latter function just uses normal C API calls to actually invoke the runpy code (specifically "runpy._run_module_as_main()"). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problems with events in a numeric keyboard
Hi! I'm trying to catch the triple zero (000) key from a numeric keyboard but, I found that it's the same id that the single zero. So, when I press the triple zero key once, I receive three events from the single zero key. I need to make a disctintion between these keys, and use them to different functionalities. How can I do? Martín. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with events in a numeric keyboard
On Wed, 26 Aug 2009 01:17:50 am Martin Zugnoni wrote: > Hi! I'm trying to catch the triple zero (000) key from a numeric > keyboard... This list is for the development *of* the Python language, not development *with* Python. You should probably try the comp.lang.python newsgroup, also available as a mailing list: http://www.python.org/mailman/listinfo/python-list Good luck. -- Steven D'Aprano ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runpy.py
Take a look at two PEPs referenced in runpy doc, http://docs.python.org/3.1/library/runpy.html : PEP 338 - Executing modules as scripts PEP written and implemented by Nick Coghlan. PEP 366 - Main module explicit relative imports PEP written and implemented by Nick Coghlan. (Nick is too modest to self-reference, but these two PEPs give an excellent exposition. :-) On Tue, Aug 25, 2009 at 5:01 AM, Nick Coghlan wrote: > Benjamin Peterson wrote: >> 2009/8/25 Chris Withers : >> >>> Anyway, so how is the stuff in runpy.py wired up to the command line options >>> passed to the interpretter? >> >> Modules/main.c > > The most relevant functions in there are "RunMainFromImporter()" > (attempting zipfile/directory execution) and "RunModule()" (-m switch > and also called for zipfile/directory execution). The latter function > just uses normal C API calls to actually invoke the runpy code > (specifically "runpy._run_module_as_main()"). > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > --- > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/alexander.belopolsky%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Excluding the current path from module search path?
Hi All, I'm being bitten by this issue: http://bugs.python.org/issue1734860 I'm not sure I agree with Daniel's closing of it so thought I'd ask here... Am I right in thinking that the general idea is that "the current working directory at the time of invoking a script or interpreter ends up on the python path" or should I be thinking "the directory that a script exists in should end up on the python path"? If the latter, then what happens in the case of just starting up an interpreter? If neither, then how come when I have two .py files in a directory, I can import one as a module from the other? In any case, as a parting comment, http://bugs.python.org/issue1232023 seems to have been committed with no tests and the only documentation being a one liner in the NEWS.txt file. Was there other discussion of this? (Incidentally, export PYTHONPATH= or its Windows equivalent circumvents whatever the patch was trying to achieve, so the change doesn't seem to make sense anyway...) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Fri, Aug 21, 2009 at 4:00 AM, Oleg Broytmann wrote: > http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ipaddr.py > >> _compat_has_real_bytes = bytes != str > > Wouldn't it be nicer "bytes is not str"? it is. fixing this. Cheers, /peter > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ [email protected] > Programmers don't die, they just GOSUB without RETURN. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] deleting setdefaultencoding iin site.py is evil
Hi All,
Would anyone object if I removed the deletion of of
sys.setdefaultencoding in site.py?
I'm guessing "yes!" so thought I'd state my reasons now:
This deletion appears to be pretty flimsy; reload(sys) and you have it
back. Which is lucky, because I need it after it's been deleted...
Why? Well, because you can no longer put sitecustomize.py in a
project-specific location (http://bugs.python.org/issue1734860) and
because for some projects the only way I can deal with encoded strings
sensibly is to use setdefaultencoding, in my case at the start of a
script generated by zc.buildout's zc.recipe.egg (I *know* all the
encodings in this project are utf-8, but I don't want to go playing
whack-a-mole with whatever modules this rather large project uses that
haven't been made properly unicode aware).
Yes, it needs to be used as early as possible, and the docs should say
this, but deleting it seems to be petty in terms of stopping its use
when sitecustomize.py is too early and too system-wide and spraying
.decode('utf-8')'s all over a code base made up of a load of eggs
managed by buildout simply isn't feasible...
Thoughts?
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil
On 04:08 pm, [email protected] wrote: Hi All, Would anyone object if I removed the deletion of of sys.setdefaultencoding in site.py? I'm guessing "yes!" so thought I'd state my reasons now: This deletion appears to be pretty flimsy; reload(sys) and you have it back. Which is lucky, because I need it after it's been deleted... The ability to change the default encoding is a misfeature. There's essentially no way to write correct Python code in the presence of this feature. Using setdefaultencoding is never the sensible way to deal with encoded strings. Actually exposing this function in the sys module would lead all kinds of people who haven't fully grasped the way str, unicode, and encodings work to doing horrible things to create broken programs. It's bad enough that it's already possible to get this function back with the reload(sys) trick. Why? Well, because you can no longer put sitecustomize.py in a project- specific location (http://bugs.python.org/issue1734860) and because for some projects the only way I can deal with encoded strings sensibly is to use setdefaultencoding, in my case at the start of a script generated by zc.buildout's zc.recipe.egg (I *know* all the encodings in this project are utf-8, but I don't want to go playing whack-a-mole with whatever modules this rather large project uses that haven't been made properly unicode aware). Yes, it needs to be used as early as possible, and the docs should say this, but deleting it seems to be petty in terms of stopping its use when sitecustomize.py is too early and too system-wide and spraying .decode('utf-8')'s all over a code base made up of a load of eggs managed by buildout simply isn't feasible... Thoughts? It may be a major task, but the best thing you can do is find each str and unicode operation in the software you're working with and make them correct with respect to your inputs and outputs. Flipping a giant switch for the entire process is just going to change which things are wrong. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Excluding the current path from module search path?
At 04:59 PM 8/25/2009 +0100, Chris Withers wrote: Hi All, I'm being bitten by this issue: http://bugs.python.org/issue1734860 I'm not sure I agree with Daniel's closing of it so thought I'd ask here... Am I right in thinking that the general idea is that "the current working directory at the time of invoking a script or interpreter ends up on the python path" or should I be thinking "the directory that a script exists in should end up on the python path"? If the latter, then what happens in the case of just starting up an interpreter? It's the latter. In the case where there is no script, then the current directory is considered to be the directory of the script. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Excluding the current path from module search path?
2009/8/25 Chris Withers : > Hi All, > > I'm being bitten by this issue: > > http://bugs.python.org/issue1734860 > > I'm not sure I agree with Daniel's closing of it so thought I'd ask here... > > Am I right in thinking that the general idea is that "the current working > directory at the time of invoking a script or interpreter ends up on the > python path" or should I be thinking "the directory that a script exists in > should end up on the python path"? The latter. > > If the latter, then what happens in the case of just starting up an > interpreter? Because '' is prepended to sys.path then. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Excluding the current path from module search path?
On Tue, 25 Aug 2009 at 16:59, Chris Withers wrote: In any case, as a parting comment, http://bugs.python.org/issue1232023 seems to have been committed with no tests and the only documentation being a one liner in the NEWS.txt file. Was there other discussion of this? It probably should have gone into What's New as well, but it was too late for that at the time the bug was filed. (Incidentally, export PYTHONPATH= or its Windows equivalent circumvents whatever the patch was trying to achieve, so the change doesn't seem to make sense anyway...) The change was fixing a clear bug: blank path elements were being introduced into the path _unintentionally_ and unexpectedly. Setting PYTHONPATH would be a way to do it intentionally. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil
Chris Withers wrote:
> Hi All,
>
> Would anyone object if I removed the deletion of of
> sys.setdefaultencoding in site.py?
>
> I'm guessing "yes!" so thought I'd state my reasons now:
>
> This deletion appears to be pretty flimsy; reload(sys) and you have it
> back. Which is lucky, because I need it after it's been deleted...
>
> Why? Well, because you can no longer put sitecustomize.py in a
> project-specific location (http://bugs.python.org/issue1734860) and
> because for some projects the only way I can deal with encoded strings
> sensibly is to use setdefaultencoding, in my case at the start of a
> script generated by zc.buildout's zc.recipe.egg (I *know* all the
> encodings in this project are utf-8, but I don't want to go playing
> whack-a-mole with whatever modules this rather large project uses that
> haven't been made properly unicode aware).
>
> Yes, it needs to be used as early as possible, and the docs should say
> this, but deleting it seems to be petty in terms of stopping its use
> when sitecustomize.py is too early and too system-wide and spraying
> .decode('utf-8')'s all over a code base made up of a load of eggs
> managed by buildout simply isn't feasible...
>
> Thoughts?
Let's look at this from another angle: sys.setdefaultencoding()
is only made available for use in site.py. This is documented
and by design (since a site may want to set the default encoding
based on the locale or to "utf-8").
If you use it anywhere else, you're on your own. Such usage
is not supported and may very well break your interpreter or
cause data corruption (the default encoded versions of Unicode
objects are cached inside the objects).
Now, in your particular case, you're probably better off just
tweaking site.py directly in your custom Python interpreter
rather than relying on sitecustomize.py (see setencoding() in
site.py).
To answer your question: yes, this particular API may not be
used outside site.py.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 25 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil
In retrospect, it should have been called sys._setdefaultencoding(). That sends an extra signal that it's not meant for general use. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Mon, Aug 24, 2009 at 9:54 PM, Peter Moody wrote: > I personally hope that's not required; yours has been the only > dissenting email and I believe I respond to all of your major points > here. Silence is not assent. ipaddr looks like a reasonable library from here, but AFAIK it's not widely used outside of google. I don't know if it's reasonable to want some amount public usage before a brand-new API goes into the standard library, but such use is more likely to uncover API flaws or quirks than a PEP. -jake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil
On 2009-08-25 12:37 PM, Guido van Rossum wrote: In retrospect, it should have been called sys._setdefaultencoding(). That sends an extra signal that it's not meant for general use. Considering all of the sys._getframe() hacks out there, I suspect that this would encourage more abuse of the function than the current situation. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil
On Tue, Aug 25, 2009 at 11:10 AM, Robert Kern wrote: > On 2009-08-25 12:37 PM, Guido van Rossum wrote: >> >> In retrospect, it should have been called sys._setdefaultencoding(). >> That sends an extra signal that it's not meant for general use. > > Considering all of the sys._getframe() hacks out there, I suspect that this > would encourage more abuse of the function than the current situation. Why? It would still be deleted by site.py. The abuse of sys._getframe() exists because it fills a real need. (As does abuse of sys.setdefaultencoding(). However abusing it is actually more troublesome, because the problems are much less theoretical.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil
On 2009-08-25 13:29 PM, Guido van Rossum wrote: On Tue, Aug 25, 2009 at 11:10 AM, Robert Kern wrote: On 2009-08-25 12:37 PM, Guido van Rossum wrote: In retrospect, it should have been called sys._setdefaultencoding(). That sends an extra signal that it's not meant for general use. Considering all of the sys._getframe() hacks out there, I suspect that this would encourage more abuse of the function than the current situation. Why? It would still be deleted by site.py. Ah, yes. You're right. For whatever reason I thought it lived as site.setdefaultencoding() when I read your message and thought that you were proposing to move it to sys. Never mind me. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
> ipaddr looks like a reasonable library from here, but AFAIK it's not > widely used outside of google. I don't know if it's reasonable to > want some amount public usage before a brand-new API goes into the > standard library, but such use is more likely to uncover API flaws or > quirks than a PEP. OTOH, the PEP process *is* the stronger of the two approaches, allowing people to provide explicit opinions even if (and especially if) they dislike the technology entirely (whereas for an external module, they would just ignore it). If they refuse the comment, they can't complain when it gets added to the standard library - they can still chose to ignore it, then, of course (just as many people ignore xml.dom). In the specific case, I'm not worried about timing. Either 2.7 or 3.2 are still a year ahead, which should give people plenty of time to experiment. OTTH, I *like* people to comment strongly on the PEP, in particular if they are authors of competing libraries. It's no surprise that they get emotional when their hard work won't be appropriately honored in the long run - and if they believe there is something wrong with the technology being proposed (rather than just the words used to describe it), they are probably right. I said it before - this is not going to be a fast acceptance path of a library that gets accepted just because GvR works at google. People of competing libraries *could* write competing PEPs if they wanted to see their library incorporated instead - or they can just state that they don't want *this* library to be incorporated for specific technical reasons. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
