Re: [Python-Dev] Python signal processing question
Glyph Lefkowitz wrote: The selection of RuntimeError in this particular case seems somewhat random and ad-hoc, Indeed -- usually a RuntimeError indicates that something concerning the internals of Python itself is screwed up, e.g. attempting to execute invalid bytecode. The fact that it turns up here may be a historical accident. I can imagine that the signal module dates back to the very early days of Python, when the conventions for error reporting were not so well formed. Maybe this is something that could be considered in the exception hierarchy revamp proposal that was posted recently? -- Greg ___ 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] Python Language Summit EuroPython 2010
On Wed, Jul 21, 2010 at 16:58, Antoine Pitrou wrote: > On Wed, 21 Jul 2010 11:42:00 -0400 > Jesse Noller wrote: > > On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden > wrote: > > [...snip...] > > > A messy discussion turned on the question of garbage collection of > module > > > objects, and the order in which finalisers are called if at all, > especially > > > when reference cycles exist. Marc Andre was proposing a __cleanup__ > magic > > > function > > > for Python modules, which would enable the implementer to define the > order > > > in which resources are released / closed down. This is quite a subtle > area > > > and raised the issue of unfinalised objects in a reference cycle whose > > > memory has been freed out from under them but which still exist. Martin > > > described > > > the Java approach where finalisers are called once and then flagged so > > > they are not called again even if their object is resurrected. This > sounded > > > like a useful approach for Python but would break code which expected > to > > > be able to resurrect an object during its __del__ method... which is > not > > > expected to account for much code. > > > > > > Guido pointed out that no-one can be expected to hold enough of the > > > complexities > > > of this area of Python's implementation in their head, and that an > > > implementation > > > of some sort would need to be written so that the corner-cases could > emerge. > > > > FWIW; I'm currently dealing with a bug in this area w.r.t > > multiprocessing and threads and modules we have imported vanishing due > > to this issue. I'm interested in hearing more. > > One common resolution is to not use a __del__ method, but instead a > weakref callback which will do the necessary cleanup of a certain set > of resources. This is of course not applicable in all situations. That's an option. I just remember Tim bringing up something about that approach that didn't quite work as a complete replacement for __del__. Basically the whole setting a module's globals to None was done before gc came into the language. Now that it's there it seems that it might work to simply let gc clean up the module itself. But this brings in the question of how to order calling finalizers. It seemed the room had no specific answer other than it might just have to be near random as figuring out a reasonable order is hard. ___ 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] Python Language Summit EuroPython 2010
On Thu, Jul 22, 2010 at 9:51 AM, Brett Cannon wrote: > > > On Wed, Jul 21, 2010 at 16:58, Antoine Pitrou wrote: >> >> On Wed, 21 Jul 2010 11:42:00 -0400 >> Jesse Noller wrote: >> > On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden >> > wrote: >> > [...snip...] >> > > A messy discussion turned on the question of garbage collection of >> > > module >> > > objects, and the order in which finalisers are called if at all, >> > > especially >> > > when reference cycles exist. Marc Andre was proposing a __cleanup__ >> > > magic >> > > function >> > > for Python modules, which would enable the implementer to define the >> > > order >> > > in which resources are released / closed down. This is quite a subtle >> > > area >> > > and raised the issue of unfinalised objects in a reference cycle whose >> > > memory has been freed out from under them but which still exist. >> > > Martin >> > > described >> > > the Java approach where finalisers are called once and then flagged so >> > > they are not called again even if their object is resurrected. This >> > > sounded >> > > like a useful approach for Python but would break code which expected >> > > to >> > > be able to resurrect an object during its __del__ method... which is >> > > not >> > > expected to account for much code. >> > > >> > > Guido pointed out that no-one can be expected to hold enough of the >> > > complexities >> > > of this area of Python's implementation in their head, and that an >> > > implementation >> > > of some sort would need to be written so that the corner-cases could >> > > emerge. >> > >> > FWIW; I'm currently dealing with a bug in this area w.r.t >> > multiprocessing and threads and modules we have imported vanishing due >> > to this issue. I'm interested in hearing more. >> >> One common resolution is to not use a __del__ method, but instead a >> weakref callback which will do the necessary cleanup of a certain set >> of resources. This is of course not applicable in all situations. > > That's an option. I just remember Tim bringing up something about that > approach that didn't quite work as a complete replacement for __del__. > Basically the whole setting a module's globals to None was done before gc > came into the language. Now that it's there it seems that it might work to > simply let gc clean up the module itself. But this brings in the question of > how to order calling finalizers. It seemed the room had no specific answer > other than it might just have to be near random as figuring out a reasonable > order is hard. If you have a cycle, there is no other way than breaking it at random, right? Cheers, fijal ___ 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] Python signal processing question
Greg Ewing writes: > Glyph Lefkowitz wrote: > > > The selection of RuntimeError in this particular case seems > > somewhat random and ad-hoc, Well, I guess we'd have to catch the person who wrote the code and ask. > Maybe this is something that could be considered in the > exception hierarchy revamp proposal that was posted recently? I think that's Antoine's PEP 3151. Interestingly, he doesn't mention EINVAL at all. http://www.python.org/dev/peps/pep-3151/ ___ 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] Python Language Summit EuroPython 2010
On Jul 21, 2010, at 04:11 PM, Tim Golden wrote: >The email module needs some work in Py3. David Murray has been given >some money by the PSF but needs more from other sources to complete >the work. This is hampered by the legalities around commercial >organisations making donations to not-for-profits when those donations >are earmarked. Various suggestions were put forward with no-one sure >of the legal issues. Guido suggested that we should move forward >rather than stall for want of legal advice. +1 please! Or contact the folks at the FSF for their experiences. I know that they accept tax exempt donations targeted for specific projects. Of course, when they disburse funds to developers, those developers may incur tax liabilities, but that's a different matter. >Martin spoke about the state of the stable ABI PEP, indicating that he >was targetting 3.2. This work would reduce the need to recompile >extension modules separately on Windows for every version of Python -- >something especially pertinent when code has been orphaned but is >still useful. The versioned .so files PEP being worked out by Barry >Warsaw overlaps with this PEP and would only be useful for extensions >which don't target the stable ABI. Right. Expect an update to PEP 3149 later today, along with more followups to that thread, and an updated patch. I'd also like to see the stable ABI make it into Python 3.2. It's a longer term project in the sense that it will take time for extensions to be written against the ABI. Getting it into Python 3.2 will allow that process to start, but I think even that doesn't eliminate the need for versioned .so files because there will always be extensions accessing API outside PEP 384. I'd still like to help work on the implementation of PEP 384. It would be helpful for folks who care about it to comment on the substance of the PEP. -Barr signature.asc Description: PGP signature ___ 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] Python-dev signal-to-noise processing question
Oleg Broytman writes: > On Wed, Jul 21, 2010 at 07:28:24PM -0600, average wrote: > > As to your question of how best to handle inquiries from the blue or > > "noisy questions", I personally prefer the following (only slightly > > tongue-in-cheek): > > > > ...After a sufficient period of waiting, say a day or two with no response: > >Ok, I'll wait a bit longer. I don't think that's a good idea. It just encourages people to give a response on python-dev plus follow-ups, and if they give an answer without saying "you'd better ask this on comp.lang.python", when you do, you look like a netcop rather than being helpful. The mail you originally sent was sufficiently polite and clear IMO, but anything can be improved and I'm glad you took up the suggestions on the wording. OTOH I think as quick as possible an answer is a good idea here. It saves the intended audience the thought about whether to reply or not, and an instant, constructive answer says that somebody cares. The message should be "The people who will answer your question on python-dev are also on comp.lang.python, as well as many more (you may get a faster, and probably more complete, answer on comp.lang.python). The people on python-dev don't need to see the answer (they already know it), but the people on comp.lang.python are likely to be happy to learn it." ___ 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] EINVAL
On Thu, 22 Jul 2010 17:50:00 +0900 "Stephen J. Turnbull" wrote: > Greg Ewing writes: > > Glyph Lefkowitz wrote: > > > > > The selection of RuntimeError in this particular case seems > > > somewhat random and ad-hoc, > > Well, I guess we'd have to catch the person who wrote the code and > ask. > > > Maybe this is something that could be considered in the > > exception hierarchy revamp proposal that was posted recently? > > I think that's Antoine's PEP 3151. Interestingly, he doesn't mention > EINVAL at all. > > http://www.python.org/dev/peps/pep-3151/ That's right. It is based on a survey of existing exception-catching code in the stdlib. There's only one match in the whole Lib/ subtree: $ grep -r EINVAL Lib/ Lib/plat-sunos5/STROPTS.py:968:EINVAL = 22 I guess EINVAL would most often indicate a programming error, which is why it doesn't get handled specifically in except clauses. Semantically, EINVAL seems close to ValueError. If I search inside the man pages here, I get excerpts such as: - wait(2): EINVAL The options argument was invalid. - gettimeofday(2): EINVAL Timezone (or something else) is invalid. - socket(2): EINVAL Unknown protocol, or protocol family not available. EINVAL Invalid flags in type. - rename(2): EINVAL The new pathname contained a path prefix of the old, or, more generally, an attempt was made to make a directory a subdirectory of itself. Regards Antoine. ___ 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] New regex module for 3.2?
Am 13.07.2010 15:35, schrieb Antoine Pitrou: > On Tue, 13 Jul 2010 15:20:23 +0100 > Michael Foord wrote: >> On 13/07/2010 15:17, Reid Kleckner wrote: >> > On Mon, Jul 12, 2010 at 2:07 PM, Nick Coghlan wrote: >> > >> >> MRAB's module offers a superset of re's features rather than a subset >> >> though, so once it has had more of a chance to bake on PyPI it may be >> >> worth another look. >> >> >> > I feel like the new module is designed to replace the current re >> > module, and shouldn't need to spend time in PyPI. A faster regex >> > library isn't going to motivate users to add external dependencies to >> > their projects. >> > >> > >> If the backwards compatibility issues can be addressed and MRAB is >> willing to remain as maintainer then the advantages seem well worth it >> to me. > > To me as well. The code needs a full review before integrating, though. FWIW, I've now run the Pygments test suite (Pygments has about 2500 regular expressions that are exercised there) and only had two problems: * Scoped flags: A few lexers use (?s) and similar flags at the end of the expression, which has no effect in regex currently. * POSIX character classes: One regex used a class '[][:xyz]', so the [: was seen as the start of a character class. I'm not sure how common this is, as most people seem to escape brackets in character classes. Also, it gives a clear error on regex.compile(), not "mysterious" failures. Timings (seconds to run the test suite): re 26.689 26.015 26.008 regex 26.066 25.797 25.865 So, I thought there wasn't a difference in performance for this use case (which is compiling a lot of regexes and matching most of them only a few times in comparison). However, I found that looking at the regex caching is very important in this case: re._MAXCACHE is by default set to 100, and regex._MAXCACHE to 1024. When I set re._MAXCACHE to 1024 before running the test suite, I get times around 18 (!) seconds for re. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Python-dev signal-to-noise processing question
On Thu, Jul 22, 2010 at 06:02:33PM +0900, Stephen J. Turnbull wrote: > Oleg Broytman writes: > > On Wed, Jul 21, 2010 at 07:28:24PM -0600, average wrote: > > > As to your question of how best to handle inquiries from the blue or > > > "noisy questions", I personally prefer the following (only slightly > > > tongue-in-cheek): > > > > > > ...After a sufficient period of waiting, say a day or two with no > response: > > > >Ok, I'll wait a bit longer. > > I don't think that's a good idea. It just encourages people to give a > response on python-dev plus follow-ups, and if they give an answer > without saying "you'd better ask this on comp.lang.python", when you > do, you look like a netcop rather than being helpful. Yes, that's a kind of a problem. Not a big one - I live in the "wrong" time zone and can afford to wait a few hours. Certainly not a few days. > The mail you originally sent was sufficiently polite and clear IMO, > but anything can be improved and I'm glad you took up the suggestions > on the wording. > > OTOH I think as quick as possible an answer is a good idea here. It > saves the intended audience the thought about whether to reply or not, > and an instant, constructive answer says that somebody cares. The > message should be "The people who will answer your question on > python-dev are also on comp.lang.python, as well as many more (you may > get a faster, and probably more complete, answer on comp.lang.python). > The people on python-dev don't need to see the answer (they already > know it), but the people on comp.lang.python are likely to be happy to > learn it." Thank you. I'll think how to add something like this so that my boilerplate wouldn't become too big, Oleg. -- Oleg Broytmanhttp://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/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Fri, Jul 16, 2010 at 6:08 PM, Georg Brandl wrote: > Nevertheless, the authoritative reference for our regex engine is its > docs, i.e. http://docs.python.org/library/re.html -- and that states > clearly that inline flags apply to the whole regex. > >> I think with a new regex implementation, not all of this "historical" >> semantics must be copied, unless there are major real usecases, which >> would be affected by this. > > As I already said, I *have* seen this in real code. As MRAB indicated, > this was the only silent change in semantics as compared to the old > regex engine. If we replace re by regex, which I think is the only > way to get the new features in the stdlib, changing this one aspect is > a) not backwards compatible and b) in a subtle way that forces everyone > to review his/her regular expressions. That's definitely not > acceptable. I wonder if the solution could be a new flag that you have to specify if you want the flags to apply locally only. Let's say add 'L' to the flags. Then for existing code (not using 'L') the flags should apply globally, while someone wanting flags to apply to only part of a regex can add 'L' to the flags syntax. Is that acceptable? -- --Guido van Rossum (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
[Python-Dev] Python 3 optimizations...
Hello, during the last year, I have developed a couple of quickening-based optimizations for the Python 3.1 interpreter. As part of my PhD programme, I have published a first technique that combines quickening with inline caching at this year's ECOOP, and subsequently extended this technique to optimize several load instructions as well as eliminate redundant reference counting operations from instructions, which has been accepted for publication for an upcoming conference. I have a working prototype combining all of these optimizations that achieves a maximum speedup of 2.18 on the spectralnorm benchmark of the computer language benchmarks game. Early measurements on the Unladen Swallow django benchmark (with Martin von Loewis' patch for Python 3) achieve a speedup of about 1.3. Both speedups were measured on an i7 920 when combined with the threaded code/computed goto optimization enabled, and normalized by the standard Python 3.1 interpreter with all optimizations disabled. Since all of these optimizations are purely interpretative, they have next-to-no additional memory requirements and do not incur extensive warm-up costs. I wonder whether you would be interested in integrating these optimizations with the Python 3 distribution, hence this mail. I could send copies of the papers, as well as provide my prototype source code to interested members of the python development community. Have a nice day, --stefan ___ 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] Python Language Summit EuroPython 2010
On Thu, 22 Jul 2010 08:51:57 +0100 Brett Cannon wrote: > > That's an option. I just remember Tim bringing up something about that > approach that didn't quite work as a complete replacement for __del__. > > Basically the whole setting a module's globals to None was done before gc > came into the language. Now that it's there it seems that it might work to > simply let gc clean up the module itself. There is a patch at http://bugs.python.org/issue812369 for GC-based module shutdown, but it doesn't actually remove the setting of module globals to None. I think further testing and experimentation would be required to validate it. Regards Antoine. ___ 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] Python-dev signal-to-noise processing question
On Thu, 22 Jul 2010 07:02:33 pm Stephen J. Turnbull wrote: > OTOH I think as quick as possible an answer is a good idea here. It > saves the intended audience the thought about whether to reply or > not, and an instant, constructive answer says that somebody cares. +1 I think that waiting "a day or two" as suggested by Average does nobody any good. It doesn't help the poster, who will almost certainly have given up by then, and may have concluded that we're stuck-up and rude for not answering a polite question. It doesn't help those who choose to reply, because we're sitting around wondering if we've waiting long enough. If you consider posting a question to a list without making any effort to determine whether it is on-topic or not to be a social faux pas, and therefore worthy of a mild rebuke, the longer you wait the less effective the negative reinforcement is. Even if you don't see it like that, and just want to point the poster in the right direction, there's still no advantage in waiting. But frankly, I think we're worrying too much. What exactly are we worried about? As I see it, the worst that can happen is a false negative, somebody will say "You've posted to the wrong list" and will be corrected by somebody else who says "No, you've misunderstood the question, this is the right list". No harm done. > The message should be "The people who will answer your question on > python-dev are also on comp.lang.python, as well as many more (you > may get a faster, and probably more complete, answer on > comp.lang.python). The people on python-dev don't need to see the > answer (they already know it), but the people on comp.lang.python are > likely to be happy to learn it." We don't need to make excuses for why we don't give the answer here. It's enough to give the reason -- it's off-topic for this list, which is about the development of Python. That and a pointer to the right list is, in my opinion, all we need to say. We don't need to sugar coat it -- we're all adults here. -- 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] Python Language Summit EuroPython 2010
2010/7/22 Antoine Pitrou : > On Thu, 22 Jul 2010 08:51:57 +0100 > Brett Cannon wrote: >> >> That's an option. I just remember Tim bringing up something about that >> approach that didn't quite work as a complete replacement for __del__. >> >> Basically the whole setting a module's globals to None was done before gc >> came into the language. Now that it's there it seems that it might work to >> simply let gc clean up the module itself. > > There is a patch at http://bugs.python.org/issue812369 for GC-based > module shutdown, but it doesn't actually remove the setting of module > globals to None. I think further testing and experimentation would be > required to validate it. Also, it seems to have been stalled by static globals in extension modules that the gc doesn't know about. -- 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] module shutdown procedure
Le jeudi 22 juillet 2010 à 07:23 -0500, Benjamin Peterson a écrit : > 2010/7/22 Antoine Pitrou : > > On Thu, 22 Jul 2010 08:51:57 +0100 > > Brett Cannon wrote: > >> > >> That's an option. I just remember Tim bringing up something about that > >> approach that didn't quite work as a complete replacement for __del__. > >> > >> Basically the whole setting a module's globals to None was done before gc > >> came into the language. Now that it's there it seems that it might work to > >> simply let gc clean up the module itself. > > > > There is a patch at http://bugs.python.org/issue812369 for GC-based > > module shutdown, but it doesn't actually remove the setting of module > > globals to None. I think further testing and experimentation would be > > required to validate it. > > Also, it seems to have been stalled by static globals in extension > modules that the gc doesn't know about. Is it the reason why? With the new module creation API in 3.x, extension modules should be able to handle deletion of their own internal resources. Regards Antoine. ___ 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] Set the namespace free!
Hello, guys.
Python has more and more reserved words over time. It becomes quite annoying,
since you can not use variables and attributes of such names. Suppose I want to
make an XML parser that reads a document and returns an object with attributes
corresponding to XML element attributes:
> elem = parse_xml("")
> print elem.param
boo
What should I do then, when the attribute is a reserver word? I could use
trailing underscore, but this is quite ugly and introduces ambiguity.
> elem = parse_xml("")
> print elem.for_ #?
> elem = parse_xml("")
> print elem.for__ #?
My proposal: let's make a syntax change.
Let all reserved words be preceded with some symbol, i.e. "!" (exclamation
mark). This goes also for standard library global identifiers.
!for boo in foo:
!if boo is !None:
!print(hoo)
!else:
!return !sorted(woo)
This would allow the user to declare any identifier with any name:
for = with(return) + try
What do you think of it? It is a major change, but I think Python needs it.
--
haael
___
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] Python 3 optimizations...
On Thu, 22 Jul 2010 13:22:48 +0200 stefan brunthaler wrote: > > I wonder whether you would be interested in integrating these > optimizations with the Python 3 distribution, hence this mail. I could > send copies of the papers, as well as provide my prototype source code > to interested members of the python development community. Is the source code under an open source non-copyleft license? Have you checked that the whole regression test suite passes? Can you publish all this online (papers and source code)? Regards Antoine. ___ 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] Set the namespace free!
On 22 July 2010 15:04, Bartosz Tarnowski wrote:
> What should I do then, when the attribute is a reserver word?
You would use elem.getattr('param'). That's what it's for.
> Let all reserved words be preceded with some symbol, i.e. "!" (exclamation
> mark).
Oh, God, no.
This would be better off on the Python Ideas list. Well, it would be
better of stone dead IMHO, but better ideas than here.
--
Cheers,
Simon B.
___
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] Set the namespace free!
On Thu, 22 Jul 2010, Bartosz Tarnowski wrote: [] My proposal: let's make a syntax change. I'm pretty sure this belongs on python-ideas. Let all reserved words be preceded with some symbol, i.e. "!" (exclamation mark). This goes also for standard library global identifiers. !for boo in foo: !if boo is !None: !print(hoo) !else: !return !sorted(woo) Is today April 1st? Seriously, an identifier-quoting capability like PostgreSQL has wouldn't necessarily be a bad idea, but would be a topic for python-ideas, not here on python-dev. Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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] Distutils reverted in py3k
Hello As decided during the summit, I've reverted Distutils in the py3k branch, to its release3.1-maint state. This was already done in 2.7. I will only work on bugfixes for now on for distutils. Everything new is done in distutils2. So if you have a feature request, use the distutils2 component in the tracker. Let me know if you have/see any problem this revert created. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ 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] Distutils reverted in py3k
Note that I'll revert Doc/distutils as well, but I need to check first with Ronald a few Mac OS X points. ___ 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] module shutdown procedure
2010/7/22 Antoine Pitrou : > Le jeudi 22 juillet 2010 à 07:23 -0500, Benjamin Peterson a écrit : >> 2010/7/22 Antoine Pitrou : >> > On Thu, 22 Jul 2010 08:51:57 +0100 >> > Brett Cannon wrote: >> >> >> >> That's an option. I just remember Tim bringing up something about that >> >> approach that didn't quite work as a complete replacement for __del__. >> >> >> >> Basically the whole setting a module's globals to None was done before gc >> >> came into the language. Now that it's there it seems that it might work to >> >> simply let gc clean up the module itself. >> > >> > There is a patch at http://bugs.python.org/issue812369 for GC-based >> > module shutdown, but it doesn't actually remove the setting of module >> > globals to None. I think further testing and experimentation would be >> > required to validate it. >> >> Also, it seems to have been stalled by static globals in extension >> modules that the gc doesn't know about. > > Is it the reason why? With the new module creation API in 3.x, extension > modules should be able to handle deletion of their own internal > resources. Well, then the reason is that no modules use it. I also believe the new API is dangerous because modules can be deallocated before objects in them resulting in segfaults when those objects require globals stored in the module state. -- 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] Python 3 optimizations...
> Is the source code under an open source non-copyleft license? > I am (unfortunately) not employed or funded by anybody, so I think that I can license/release the code as I see fit. > Have you checked that the whole regression test suite passes? > Currently, I am sure my prototype will not pass the regression test suite, because I used it for benchmarking only. However, I think it is probably not a too much work to get this done. > Can you publish all this online (papers and source code)? > I am not sure whether I can publish the ECOOP paper without violating any Springer copyrights, but will check if that is any problem. I could send you the second paper in private; until it is going to be published in the corresponding proceedings, I fear that I might not be able to put this online, though. Publishing the source code should not be a problem at all, though I think some polishing might not be a bad idea... Best, --stefan ___ 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] New regex module for 3.2?
On Thu, Jul 22, 2010 at 9:34 PM, Georg Brandl wrote: > So, I thought there wasn't a difference in performance for this use case > (which is compiling a lot of regexes and matching most of them only a > few times in comparison). However, I found that looking at the regex > caching is very important in this case: re._MAXCACHE is by default set to > 100, and regex._MAXCACHE to 1024. When I set re._MAXCACHE to 1024 before > running the test suite, I get times around 18 (!) seconds for re. That still fits with the compile/match performance trade-off changes between re and regex though. It does make it clear this isn't going to be a win across the board though - things like test suites are going to have more one-off regex operations than a long-running web server or a filesystem or database scanning operation. 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
Re: [Python-Dev] Set the namespace free!
On 2010-07-22, at 14:45 , Simon Brunning wrote:
> On 22 July 2010 15:04, Bartosz Tarnowski
> wrote:
>> What should I do then, when the attribute is a reserver word?
>
> You would use elem.getattr('param'). That's what it's for.
getattr(elem, 'param') I believe, rather than elem.getattr('param')
___
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] module shutdown procedure
Am 22.07.2010 13:29, schrieb Antoine Pitrou: > Le jeudi 22 juillet 2010 à 07:23 -0500, Benjamin Peterson a écrit : >> 2010/7/22 Antoine Pitrou : >> > On Thu, 22 Jul 2010 08:51:57 +0100 >> > Brett Cannon wrote: >> >> >> >> That's an option. I just remember Tim bringing up something about that >> >> approach that didn't quite work as a complete replacement for __del__. >> >> >> >> Basically the whole setting a module's globals to None was done before gc >> >> came into the language. Now that it's there it seems that it might work to >> >> simply let gc clean up the module itself. >> > >> > There is a patch at http://bugs.python.org/issue812369 for GC-based >> > module shutdown, but it doesn't actually remove the setting of module >> > globals to None. I think further testing and experimentation would be >> > required to validate it. >> >> Also, it seems to have been stalled by static globals in extension >> modules that the gc doesn't know about. > > Is it the reason why? With the new module creation API in 3.x, extension > modules should be able to handle deletion of their own internal > resources. Yes, but as Martin noted at the summit, nobody since went through all the extension modules and changed them to use a struct instead of globals. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Set the namespace free!
On 22 July 2010 14:14, Xavier Morel wrote:
> getattr(elem, 'param') I believe, rather than elem.getattr('param')
Doh! You're absolutely right, of course.
--
Cheers,
Simon B.
___
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] Python 3 optimizations...
On Thu, Jul 22, 2010 at 9:22 PM, stefan brunthaler wrote: > I wonder whether you would be interested in integrating these > optimizations with the Python 3 distribution, hence this mail. I could > send copies of the papers, as well as provide my prototype source code > to interested members of the python development community. The Springer link [1] at least shows the front page to give more of an idea as to what this is about. The idea does sound potentially interesting, although I'm not sure how applicable it will be with a full-blown LLVM-based JIT on the way for 3.3 (via Unladen Swallow). Depending on the size and complexity of the patches, it may still be worth exploring for 3.2. Regards, Nick. [1] http://www.springerlink.com/content/p4u0851w34180n74/ -- 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
Re: [Python-Dev] EINVAL
On 10:33 am, [email protected] wrote: On Thu, 22 Jul 2010 17:50:00 +0900 "Stephen J. Turnbull" wrote: I think that's Antoine's PEP 3151. Interestingly, he doesn't mention EINVAL at all. http://www.python.org/dev/peps/pep-3151/ That's right. It is based on a survey of existing exception-catching code in the stdlib. There's only one match in the whole Lib/ subtree: $ grep -r EINVAL Lib/ Lib/plat-sunos5/STROPTS.py:968:EINVAL = 22 I guess EINVAL would most often indicate a programming error, which is why it doesn't get handled specifically in except clauses. For setgroups it means you exceeded a platform-specific limit. On Windows, for non-blocking connect, it means wait a little longer. 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] Python 3 optimizations...
> The Springer link [1] at least shows the front page to give more of an > idea as to what this is about. > Thanks, I forgot to mention the link. > The idea does sound potentially interesting, although I'm not sure how > applicable it will be with a full-blown LLVM-based JIT on the way for > 3.3 (via Unladen Swallow). > Yeah, I see that. However, I think that a JIT compiler could very well re-use the information gathered by using my techniques to generate better code in the first run. There certainly are a couple of other benefits for combining both approaches, i.e., they are not mutually exclusive. > Depending on the size and complexity of the > patches, it may still be worth exploring for 3.2. > I am currently not aware of the planned release schedule, but I think that some of the techniques could very well be released in 3.2 -- with a conditional compilation target similar to the computed-goto feature. Regards, --stefan ___ 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] New regex module for 3.2?
Am 22.07.2010 14:12, schrieb Nick Coghlan: > On Thu, Jul 22, 2010 at 9:34 PM, Georg Brandl wrote: >> So, I thought there wasn't a difference in performance for this use case >> (which is compiling a lot of regexes and matching most of them only a >> few times in comparison). However, I found that looking at the regex >> caching is very important in this case: re._MAXCACHE is by default set to >> 100, and regex._MAXCACHE to 1024. When I set re._MAXCACHE to 1024 before >> running the test suite, I get times around 18 (!) seconds for re. > > That still fits with the compile/match performance trade-off changes > between re and regex though. It does make it clear this isn't going to > be a win across the board though - things like test suites are going > to have more one-off regex operations than a long-running web server > or a filesystem or database scanning operation. Sure -- I don't think this is a showstopper for regex. However if we don't include regex in a future version, we might think about increasing MAXCACHE a bit, and maybe not clear the cache when it reaches its max length, but rather remove another element. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] PEP 360 has outdated contents
Hello all, PEP 360 - “Externally Maintained Packages” seems to have outdated contents. First of all, I don't think Optik and wsgiref are externally maintained anymore (both seem unmaintained by their original authors). Second, the version numbers mentioned there could be out of date too (especially for ElementTree whose stdlib copy has recently been bumped by Florent). Third, it seems json should be added to the list, despite the prominent warning at the beginning that: “No new modules are to be added to this PEP. It has been deemed dangerous to codify external maintenance of any code checked into Python's code repository. Code contributers should expect Python's development methodology to be used for any and all code checked into Python's code repository.” Regards Antoine. ___ 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] versioned .so files for Python 3.2
On Jul 16, 2010, at 12:40 PM, Matthias Klose wrote: >I like the proposal, but IMO it is too unspecific about the abi tag. >Assume that an extension is built with such a configured python and >then tried to run with an abi compatible configured python, but with a >slightly different version tag, the extension won't be found. >Differing file names per configuration should be avoided. Proposing > > 1) Remove the configure option and use the new naming using the tag > for all configurations unconditionally. Everybody can expect the same > name on every installation, and PEP 384 most likely will require > using a tag too. > As Amaury did point out, there is a use case in that PyPy can > use this tag too to build extensions only usable by PyPy. > > 2) As PEP 3147 defines a non-configurable name for .pyc files, this > PEP should define a non-configurable way for the tag. The tag should > include all information which currently makes an extension ABI > incompatible: > - the python implementation (cpython, PyPy, ...) > - the python version (3,2, 3.3, ...) > - unicode configure option (--with-wide-unicode, 16 or 32) > - platform information (necessary?) > If this list changes for coming python versions, then it can be > extended. > Barry pointed out on irc chat that people might want to build > experimental ABI incompatible versions, which should have its > own tag. If this is wanted, please provide a configure option > which lets extend/append to the tag. Okay, I'm convinced we need to hard code this tag, and I think it's okay not to provide a configure switch to control this. I've pushed a new version of the diff and PEP, the latter attached here for your convenience. Thanks for all the feedback. -Barry PEP: 3149 Title: ABI version tagged .so files Version: $Revision: 81577 $ Last-Modified: $Date: 2010-05-27 19:54:25 -0400 (Thu, 27 May 2010) $ Author: Barry Warsaw Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2010-07-09 Python-Version: 3.2 Post-History: 2010-07-14, 2010-07-22 Resolution: TBD Abstract PEP 3147 [1]_ described an extension to Python's import machinery that improved the sharing of Python source code, by allowing more than one byte compilation file (.pyc) to be co-located with each source file. This PEP defines an adjunct feature which allows the co-location of extension module files (.so) in a similar manner. This optional, build-time feature will enable downstream distributions of Python to more easily provide more than one Python major version at a time. Background == PEP 3147 defined the file system layout for a pure-Python package, where multiple versions of Python are available on the system. For example, where the `alpha` package containing source modules `one.py` and `two.py` exist on a system with Python 3.2 and 3.3, the post-byte compilation file system layout would be:: alpha/ __pycache__/ __init__.cpython-32.pyc __init__.cpython-33.pyc one.cpython-32.pyc one.cpython-33.pyc two.cpython-32.pyc two.cpython-33.pyc __init__.py one.py two.py For packages with extension modules, a similar differentiation is needed for the module's .so files. Extension modules compiled for different Python major versions are incompatible with each other due to changes in the ABI. Different configuration/compilation options for the same Python version can result in different ABIs (e.g. --with-wide-unicode). While PEP 384 [2]_ defines a stable ABI, it will minimize, but not eliminate extension module incompatibilities between Python builds or major versions. Thus a mechanism for discriminating extension module file names is proposed. Rationale = Linux distributions such as Ubuntu [3]_ and Debian [4]_ provide more than one Python version at the same time to their users. For example, Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1, with Python 2.6 being the default. In order to share as much as possible between the available Python versions, these distributions install third party (i.e. non-standard library) packages into `/usr/share/pyshared` and symlink to them from `/usr/lib/pythonX.Y/dist-packages`. The symlinks exist because in a pre-PEP 3147 world (i.e < Python 3.2), the `.pyc` files resulting from byte compilation by the various installed Pythons will name collide with each other. For Python versions >= 3.2, all pure-Python packages can be shared, because the `.pyc` files will no longer cause file system naming conflicts. Eliminating these symlinks makes for a simpler, more robust Python distribution. A similar situation arises with shared library extensions. Because extension modules are typically named `foo.so` for a `foo` extension module, these would also name collide if `foo` was provided for more than one Python version
Re: [Python-Dev] Set the namespace free!
On Thu, Jul 22, 2010 at 10:04 AM, Bartosz Tarnowski
wrote:
>
> Hello, guys.
>
> Python has more and more reserved words over time. It becomes quite
> annoying, since you can not use variables and attributes of such names.
> Suppose I want to make an XML parser that reads a document and returns an
> object with attributes corresponding to XML element attributes:
>
>> elem = parse_xml("")
>> print elem.param
> boo
>
> What should I do then, when the attribute is a reserver word? I could use
> trailing underscore, but this is quite ugly and introduces ambiguity.
>
>> elem = parse_xml("")
>> print elem.for_ #?
>> elem = parse_xml("")
>> print elem.for__ #?
>
> My proposal: let's make a syntax change.
>
> Let all reserved words be preceded with some symbol, i.e. "!" (exclamation
> mark). This goes also for standard library global identifiers.
>
> !for boo in foo:
> !if boo is !None:
> !print(hoo)
> !else:
> !return !sorted(woo)
>
>
> This would allow the user to declare any identifier with any name:
>
> for = with(return) + try
>
> What do you think of it? It is a major change, but I think Python needs it.
>
> --
> haael
>
I'm not a fan of this - I'd much prefer[1] that we use the exclamation
point to determine scope:
foobar - local
!foobar - one up
!!foobar - higher than the last one
!!!foobar - even higher in scope
We could do the inverse as well; if you append ! you can push variable
down in scope.
Jesse
[1] I am not serious.
___
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] Set the namespace free!
Am 22.07.2010 15:04, schrieb Bartosz Tarnowski:
>
> Hello, guys.
>
> Python has more and more reserved words over time. It becomes quite annoying,
> since you can not use variables and attributes of such names. Suppose I want
> to
> make an XML parser that reads a document and returns an object with
> attributes
> corresponding to XML element attributes:
>
> > elem = parse_xml("")
> > print elem.param
> boo
>
> What should I do then, when the attribute is a reserver word? I could use
> trailing underscore, but this is quite ugly and introduces ambiguity.
>
> > elem = parse_xml("")
> > print elem.for_ #?
> > elem = parse_xml("")
> > print elem.for__ #?
>
> My proposal: let's make a syntax change.
>
> Let all reserved words be preceded with some symbol, i.e. "!" (exclamation
> mark). This goes also for standard library global identifiers.
>
> !for boo in foo:
> !if boo is !None:
> !print(hoo)
> !else:
> !return !sorted(woo)
You raise a good point. However, I'd rather explicitly signify names instead
of keywords:
for $boo in $foo:
if $boo is $None:
print($hoo)
else:
return sorted($woo)
That also has the advantage of introducing a measure of much needed
compatibility with industry-leading web programming languages.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
___
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] Set the namespace free!
On Thu, Jul 22, 2010 at 10:04 AM, Bartosz Tarnowski < [email protected]> wrote: > > Let all reserved words be preceded with some symbol, i.e. "!" (exclamation > mark). This goes also for standard library global identifiers. > > !for boo in foo: >!if boo is !None: >!print(hoo) >!else: >!return !sorted(woo) > > A) this should be in the 'ideas' list B) it will never ever happen. not only does it have very few benefits it makes every single piece of python code ever written invalid and it is a bad idea to arbitrarily add punctuation to the language. ___ 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] Set the namespace free!
On Thu, Jul 22, 2010 at 10:41 AM, Jesse Noller wrote: .. > I'm not a fan of this - I'd much prefer[1] that we use the exclamation > point to determine scope: > > foobar - local > !foobar - one up > !!foobar - higher than the last one > !!!foobar - even higher in scope > > We could do the inverse as well; if you append ! you can push variable > down in scope. Replace '!' with '$' and we have a winner! [IANSE] > [1] I am not serious. [IANSE] I am not serious either. ___ 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] Python 3 optimizations...
On Thu, Jul 22, 2010 at 10:08 PM, stefan brunthaler wrote: >> Is the source code under an open source non-copyleft license? >> > I am (unfortunately) not employed or funded by anybody, so I think > that I can license/release the code as I see fit. If you did this work under your PhD program, you may be more restricted than you think. You may want to check with your adviser first, cheers, 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] Set the namespace free!
On Thu, Jul 22, 2010 at 11:54 AM, Georg Brandl wrote: .. > That also has the advantage of introducing a measure of much needed > compatibility with industry-leading web programming languages. Looks like our messages crossed in flight. pathologically-eclecticly-yours ___ 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] New regex module for 3.2?
On Thu, Jul 22, 2010 at 7:42 AM, Georg Brandl wrote: > Am 22.07.2010 14:12, schrieb Nick Coghlan: >> On Thu, Jul 22, 2010 at 9:34 PM, Georg Brandl wrote: >>> So, I thought there wasn't a difference in performance for this use case >>> (which is compiling a lot of regexes and matching most of them only a >>> few times in comparison). However, I found that looking at the regex >>> caching is very important in this case: re._MAXCACHE is by default set to >>> 100, and regex._MAXCACHE to 1024. When I set re._MAXCACHE to 1024 before >>> running the test suite, I get times around 18 (!) seconds for re. It might be fun to do a pygments based macro benchmark. Just have it syntax highlight itself and time it. > Sure -- I don't think this is a showstopper for regex. However if we don't > include regex in a future version, we might think about increasing MAXCACHE > a bit, and maybe not clear the cache when it reaches its max length, but > rather remove another element. +50 for the last idea. Collin encountered a problem two summers ago in Mondrian where we were relying on the regex cache and were surprised to find that it cleared itself after filling up, rather than using LRU or random eviction. Reid ___ 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] :program: markup in .rst documentation
On Tue, Jul 20, 2010 at 20:34, Éric Araujo wrote: >> Sorry to add the third way to the mix, but shouldn't the recommended >> way to run a module as a script be python -m modname? As in >> >> $ python -m test.regrtest test_spam > > This is true but orthogonal to our problem, which is that > :program:`python -m thing` is wrong if I understood the doc rightly and > should be replaced by ``python -m thing``. > So, how can a decision be reached on this issue? I'd like to fix the relevant docs because currently there's a lot of confusion. I will fix the :program: markup together with all the :option: and :cmdoption: markup. Eli ___ 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] Set the namespace free!
On Thu, 22 Jul 2010 16:54:58 +0100 Georg Brandl wrote: > > You raise a good point. However, I'd rather explicitly signify names instead > of keywords: > > for $boo in $foo: > if $boo is $None: > print($hoo) > else: > return sorted($woo) > > That also has the advantage of introducing a measure of much needed > compatibility with industry-leading web programming languages. Also, Python would gain much needed flexibility if we allowed indirect name lookup using `$$foo`. Current abstractions are too poor compared to best-of-breed OO languages such as PHP or Perl 5. ___ 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] Set the namespace free!
On Thu, Jul 22, 2010 at 10:37 AM, Antoine Pitrou wrote: > On Thu, 22 Jul 2010 16:54:58 +0100 > Georg Brandl wrote: >> >> That also has the advantage of introducing a measure of much needed >> compatibility with industry-leading web programming languages. > > Also, Python would gain much needed flexibility if we allowed indirect > name lookup using `$$foo`. Current abstractions are too poor compared > to best-of-breed OO languages such as PHP or Perl 5. Let's not forget additional lookup operators, like %foo, to specify the kind of lookup we're interested in (whether we want the result as a dict vs. list vs. whatever). We could even allow overloading (something like object.__$__) to allow objects to customize the results of their lookup operations. Really, I think with this and a world-class regex implementation we'll be well-positioned when the Internet finally hits it big. -- Chris ___ 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] Issues #7717 and #7718 ask for Stuart Shelton contributor agreement
I believe that Pat Campbell is responsible for handling contributor agreements. I'm trying to find out if we have one from Stuart Sheldon. Could someone in the know please forward this to Pat, then we'll be able to move these issues. TIA. Mark Lawrence. ___ 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] :program: markup in .rst documentation
On Thu, Jul 22, 2010 at 11:25 AM, Eli Bendersky wrote: >>> .. shouldn't the recommended >>> way to run a module as a script be python -m modname? As in >>> >>> $ python -m test.regrtest test_spam .. > So, how can a decision be reached on this issue? I'd like to fix the > relevant docs because currently there's a lot of confusion. I will fix > the :program: markup together with all the :option: and :cmdoption: > markup. Note also that argparse/optparse does not know about -m way either: $ python -m profile -h Usage: profile.py [-o output_file_path] [-s sort] scriptfile [arg] ... I am not sure if it is possible for argparse to distinguish between -m and file name invocations, so maybe it should always use python -m modname if sys.argv[0] ends with .py. Again, this is quite important if the module being run is inside a package. ___ 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] PEP 382 progress: import hooks
At EuroPython, I sat down with Brett and we propose an approach how namespace packages get along with import hooks. I reshuffled the order in which things get done a little bit, and added a section that elaborates on the hooks. Basically, a finder will need to support a find_path method, return all .pth files, and a loader will need to support a load_module_with_path method, to initialize __path__. Please comment if you think that this needs further changes; I'll hope to start implementing it soon. 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
Re: [Python-Dev] Set the namespace free!
> > !for boo in foo: !if boo is !None: !print(hoo) !else: !return !sorted(woo) I feel most people could not bear such a difficult syntax. Why have I to type so much '!'s ? On Thu, Jul 22, 2010 at 10:04 PM, Bartosz Tarnowski < [email protected]> wrote: > > Hello, guys. > > Python has more and more reserved words over time. It becomes quite > annoying, since you can not use variables and attributes of such names. > Suppose I want to make an XML parser that reads a document and returns an > object with attributes corresponding to XML element attributes: > > > elem = parse_xml("") > > print elem.param > boo > > What should I do then, when the attribute is a reserver word? I could use > trailing underscore, but this is quite ugly and introduces ambiguity. > > > elem = parse_xml("") > > print elem.for_ #? > > elem = parse_xml("") > > print elem.for__ #? > > My proposal: let's make a syntax change. > > Let all reserved words be preceded with some symbol, i.e. "!" (exclamation > mark). This goes also for standard library global identifiers. > > !for boo in foo: >!if boo is !None: >!print(hoo) >!else: >!return !sorted(woo) > > > This would allow the user to declare any identifier with any name: > > for = with(return) + try > > What do you think of it? It is a major change, but I think Python needs it. > > -- > haael > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ysj.ray%2Bpython-dev%40gmail.com > -- Ray Allen Best wishes! ___ 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] Set the namespace free!
I agree with the idea, but a far less radical change is needed to get the desired result. The basic idea is this: it should be possible to use any name as an identifier in the syntax, including names like 'while' and 'import'. But there is no need to mess up the entire language to allow this (either by quoting all the identifiers, perl-style, or by marking the keywords). All that is needed is something like this: foo = 7 :foo = 7 # exactly like foo=7 :while= 3 # assigns 3 to variable 'while' globals()['while']=3 # current way to do this print element.:for # from example below # # keyword parameters to a function call: # BuildUrlQuery( lang='en', item='monsoon', :class='normal') # -> "?lang=en&query=monsoon&class=normal" The generic keyword function call is a really nice language feature, but it's rather impaired by the need to avoid those names which happen to be keywords. The lack of this is most painful when you are auto-generating python code which forms a bridge to another language with its own namespace (as in XML example). It's a pain when some of the names you might generate could conflict with python keywords. So, you end up using dicts and getattrs for everything and the code gets much less readable. With a simple escape like :name available, it's worthwhile to do everything with identifiers and generate the escape only as needed for these. One of the great strengths of python is the ability to form cleans and comprehensive bridges to other languages and environments (thus, in many cases, avoiding the need to write programs in those other environments :-) ). This feature would fill a gap there. The python tcl/tk interface is a bit messed up since tcl/tk uses some names for options which conflict with python keywords, and so you need to add '_' to those names. There is a feature like this in VHDL: \name\ and \while\ are identifiers, the backslashes are not part of the name, but just quote it. In VHDL you can write identifiers like \22\, and \!This?is=Strange\ as well; since VHDL creates modules that have named ports, and those modules can interface to things generated by other environments, they needed a way to assign any name to a port. For python, I'm not sure it makes sense to allow identifiers that doesn't follow the basic rule "[A-Za-z_][A-Za-z_0-9]*" -- that could break some debugging tools which expect variable names to be well-formed -- but it would be useful to be able to use any well-formed name as an identifier, including those which happen to be keywords. I've suggested :name, which doesn't break old code, and doesn't require using any new punctuation. Syntax would not change, just the lexical definition of 'identifier'. If the intent is to allow arbitrary names (not just well-formed ones), then n'name' would work better (and is consistent with existing stuff). > Date: Thu, 22 Jul 2010 10:41:39 -0400 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: [Python-Dev] Set the namespace free! > > On Thu, Jul 22, 2010 at 10:04 AM, Bartosz Tarnowski > wrote: > > > > Hello, guys. > > > > Python has more and more reserved words over time. It becomes quite > > annoying, since you can not use variables and attributes of such names. > > Suppose I want to make an XML parser that reads a document and returns an > > object with attributes corresponding to XML element attributes: > > > >> elem = parse_xml("") > >> print elem.param > > boo > > > > What should I do then, when the attribute is a reserver word? I could use > > trailing underscore, but this is quite ugly and introduces ambiguity. > > > >> elem = parse_xml("") > >> print elem.for_ #? > >> elem = parse_xml("") > >> print elem.for__ #? > > > > My proposal: let's make a syntax change. > > > > Let all reserved words be preceded with some symbol, i.e. "!" (exclamation > > mark). This goes also for standard library global identifiers. > > > > !for boo in foo: > >!if boo is !None: > >!print(hoo) > >!else: > >!return !sorted(woo) > > > > > > This would allow the user to declare any identifier with any name: > > > > for = with(return) + try > > > > What do you think of it? It is a major change, but I think Python needs it. > > > > -- > > haael > > > > I'm not a fan of this - I'd much prefer[1] that we use the exclamation > point to determine scope: > > foobar - local > !foobar - one up > !!foobar - higher than the last one > !!!foobar - even higher in scope > > We could do the inverse as well; if you append ! you can push variable > down in scope. > > Jesse > > > [1] I am not serious. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/gsmith%40alumni.uwaterloo.ca _
Re: [Python-Dev] Set the namespace free!
oops, :name does break things, e.g if x :return So, it could be ::name or |name or &name or !name or whatever. From: [email protected] To: [email protected] Subject: RE: [Python-Dev] Set the namespace free! Date: Thu, 22 Jul 2010 16:24:27 + I agree with the idea, but a far less radical change is needed to get the desired result. The basic idea is this: it should be possible to use any name as an identifier in the syntax, including names like 'while' and 'import'. But there is no need to mess up the entire language to allow this (either by quoting all the identifiers, perl-style, or by marking the keywords). All that is needed is something like this: foo = 7 :foo = 7 # exactly like foo=7 ... ___ 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] Does trace modules have a unit test?
On Wed, Jul 21, 2010 at 9:26 PM, Steve Holden wrote:
> On 7/21/2010 6:45 PM, Alexander Belopolsky wrote:
>> On Wed, Jul 21, 2010 at 1:42 PM, Benjamin Peterson
>> wrote:
>> ..
>>> True, but the tests in that file are (mostly?) all about line tracing.
>>>
>>
>> Hopefully this will change soon. :-)
>
> At which point the renaming would be justified.
True, but at that point it may be in three or more branches while
right now it is in one. It turns out, however, that the tests in the
file formerly known as test_trace cover more than line tracing, for
example:
# Test the handling of exceptions raised by each kind of trace event.
def test_call(self):
self.run_test_for_event('call')
def test_line(self):
self.run_test_for_event('line')
def test_return(self):
self.run_test_for_event('return')
def test_exception(self):
self.run_test_for_event('exception')
Furthermore, the now out of date comment in test_sys says:
# testing sys.settrace() is done in test_trace.py
which makes it clear that the original intent of test_trace was to
test everything settrace does, not just line tracing.
In any case, it looks like my original question got shadowed by the
choice of name discussion. Is it ok to rename test_trace to
test_whatever in the maintenance branches? The reason is that the
trace module is severely broken in 3.x and there are no regression
tests in 2.7 to test the 3.x port against.
Another alternative is to simply add trace module tests into
test_trace. After all, the test_sys comment I mentioned is followed
by
# testing sys.setprofile() is done in test_profile.py
The profile situation is different, though: test_profile tests the
profile module, but not sys.setprofile() .
Since there is some movement in this area, I don't think it would hurt
to make a decision now that will help writing tests in the future.
I see three solutions:
1. Minimal: do not rename test_trace in 2.7 and add trace module
tests to the existing file. Whether to revert test_trace to
test_line_tracing renaming in 3.2 can be decided after we have 2.7
tests written.
2. Rename test_trace in 2.7/3.1 and test_line_tracing in 3.2 to
test_sys_settrace.
3. Rename test_trace in 2.7/3.1 to test_line_tracing.
My preference in #2, but I can live with #1 (assuming Eli is the one
who will write the tests:-).
___
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] Python Language Summit EuroPython 2010
Thanks for writing this, Tim. On 7/21/10 11:11 AM, Tim Golden wrote: The issue of a __format__ equivalent for bytes was also raised as was the idea of object methods to render an object as string or bytes, which could be used in the polymorphic functions above. Does this mean bytes.__format__, or does it mean bytes.format? bytes.__format__ already exists, but it just calls object.__format__. I'm not sure what the desired functionality for bytes.__format__ would be. If it means bytes.format, this would be relatively easy to do in CPython, if there's agreement to add it. -- Eric. ___ 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] Set the namespace free!
On 7/22/2010 5:45 AM, [email protected] wrote: Message: 10 Date: Thu, 22 Jul 2010 16:04:00 +0200 From: Bartosz Tarnowski To:[email protected] Subject: [Python-Dev] Set the namespace free! Message-ID:<[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed Hello, guys. Python has more and more reserved words over time. It becomes quite annoying, since you can not use variables and attributes of such names. Suppose I want to make an XML parser that reads a document and returns an object with attributes corresponding to XML element attributes: > elem = parse_xml("") > print elem.param What should I do then, when the attribute is a reserver word? That's a misuse of attributes. When you need objects with unconstrained fields, inherit them from "dict", and write print(elem['param']) This protects you not only from name clashes, but from difficulties with names that don't fit Python attribute syntax. (BeautifulSoup occasionally crashes due to this problem when parsing malformed HTML). You can still provide a "__getattr__" function, if desired, for convenient access to commonly used attributes. Using "setattr" to set attributes, where the attribute string comes from an external source, can create a security hole. Remember that you can override functions on an object, for that object only, by setting an attribute. This offers the opportunity for an attack similar to SQL injection. Think about what this can do to a parser that has and calls a method "display" for each element: You are pwned. John Nagle ___ 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 382 progress: import hooks
At 01:51 PM 7/22/2010 +0100, Martin v. Löwis wrote: At EuroPython, I sat down with Brett and we propose an approach how namespace packages get along with import hooks. I reshuffled the order in which things get done a little bit, and added a section that elaborates on the hooks. Basically, a finder will need to support a find_path method, return all .pth files, and a loader will need to support a load_module_with_path method, to initialize __path__. Please comment if you think that this needs further changes; I'm not certain I understand it precisely. There seem to be some ambiguities in the spec, e.g.: "If fullname is not found, is not a package, or does not have any *.pth files, None must be returned." What does "is not a package" actually mean in that context? What happens if an empty list is returned - does that mean the importer is saying, "this is a package, whether it has an __init__.py or not?" As for the "list of strings" returned, is each string the entire contents of the .pth file? Is it to be \n-separated, or is any universal-newlines-compatible string accepted? Is there a particular order in which .pth file contents are to be returned? Regarding load_module_with_path(), how does its specification differ from simply creating a module in sys.modules, setting its __path__, and then invoking the standard load_module()? (i.e., is this method actually needed, since a correct PEP 302 loader *must* reuse an existing module object in sys.modules) I'll hope to start implementing it soon. Am I correct in understanding that, as written, one would have to redefine __import__ to implement this in a library for older Python versions? Or is it implementable as a meta_path importer? Regards, Martin Thanks for your work on this, I was just thinking about pinging to see how it was going. ;-) (I want setuptools 0.7 to be able to supply an add-on module for supporting this PEP in older Pythons, so that its current .pth hacks for implementing namespace packages can be dropped.) ___ 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] Set the namespace free!
I have no idea why my last post was a copy of the previous one. Webmail choking on a hairball. It was supposed to say: === Oops, :name does break things, e.g. if x :return So, ::name or &name or |name or whatever. I'm very amused by all the jokes about turning python into perl, but there's a good idea here that doesn't actually require that... Regards (and hoping it works this time) - Greg ___ 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] Set the namespace free!
On Thu, Jul 22, 2010 at 12:53 PM, wrote: .. > So, ::name or &name or |name or whatever. > > I'm very amused by all the jokes about turning python into perl, but there's > a good idea here that doesn't actually require that... No, there isn't. And both '&' and '|' are valid python operators that cannot be used this way. If you want ::, I think you can find a language or two to your liking. :-) ___ 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] Set the namespace free!
> Using "setattr" to set attributes, where the attribute string > comes from an external source, can create a security hole. Remember > that you can override functions on an object, for that object only, > by setting an attribute. This offers the opportunity for an attack > similar to SQL injection. Think about what this can do to a parser > that has and calls a method "display" for each element: > > > > You are pwned. Nope. You’d have to give setattr a function object, not a string. Regards ___ 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] Set the namespace free!
> Using "setattr" to set attributes, where the attribute string > comes from an external source, can create a security hole. Remember > that you can override functions on an object, for that object only, > by setting an attribute. This offers the opportunity for an attack > similar to SQL injection. Think about what this can do to a parser > that has and calls a method "display" for each element: > > > > You are pwned. Nope. You’d have to give setattr a function object, not a string. Regards ___ 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] Python-dev signal-to-noise processing question
> > > ...After a sufficient period of waiting, say a day or two with no > response: > > > > Ok, I'll wait a bit longer. > > I don't think that's a good idea. My bad, I really only meant a "sufficient delay to allow the possibility of an interested party replying". I actually figured about a day. > OTOH I think as quick as possible an answer is a good idea here. It > saves the intended audience the thought about whether to reply or not, The intended audience (the python developers or other interested lurkers) hardly need to give much thought on whether or not to reply. No one on a -dev list is expected to be a tutor. To have any reply whatsoever should be considered a bestowal of time without equal merit, or gratis. Ideally, those who aren't subscribed should get an immediate, automatic reply about resources available and how to engage the community without raising the ire of same. If there's no such automatic resource, but a designated list manager, this should be sent in private so as not to engage or bother the rest of the list with canned responses, otherwise publically so as to avoid duplication of effort. To those who *are* subscribed, they probably don't need to be told. A reference or link to ESR's "How to Ask Questions The Smart Way" (http://catb.org/esr/faqs/smart-questions.html) is a pretty good inclusion also. For those who may have never heard of it, it's pretty much the authority on developer list etiquette. $0.02, Marcos ___ 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] Set the namespace free!
On Thu, Jul 22, 2010 at 11:49 AM, Alexander Belopolsky wrote: > On Thu, Jul 22, 2010 at 12:53 PM, wrote: >> I'm very amused by all the jokes about turning python into perl, but there's >> a good idea here that doesn't actually require that... > > No, there isn't. And both '&' and '|' are valid python operators that > cannot be used this way. > > If you want ::, I think you can find a language or two to your liking. :-) A syntax for escaping reserved words used as identifiers is a worthy and interesting idea, but I don't think it's worth adding to Python. Appending '_' in the kinds of cases described by the OP is what's suggested by the style guide, and seems acceptable to me. Prefixing all reserved words with punctuation as suggested by the OP is, of course, completely ludicrous. He might just be trolling. Reid P.S. "I'm not trolling!" http://www.youtube.com/watch?v=6bMLrA_0O5I P.P.S. Sorry, I couldn't help it. ___ 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] Python 3 optimizations...
On 7/22/2010 9:36 AM, stefan brunthaler wrote: Depending on the size and complexity of the patches, it may still be worth exploring for 3.2. If your work speeds CPython, U.S. would have to be even better to knock it out. I am currently not aware of the planned release schedule, but I think that some of the techniques could very well be released in 3.2 -- with a conditional compilation target similar to the computed-goto feature. 2.6.6 is scheduled for August. 3.2 releases should start thereafter with a December target. On licenses. Look for the contributor agreement on the site. It says that you license your code on a non-exclusive basis to the PSF under one of two licenses. Both allow PSF to relicense and redistribute your code as part of a Python release. I recommend you print it out and, as someone else suggested, check with your advisor/university as to whether there is any problem with you contributing the software under one of*those particular licenses*. -- Terry Jan Reedy ___ 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] Set the namespace free!
On 7/22/2010 2:04 PM, John Nagle wrote: From: Bartosz Tarnowski Python has more and more reserved words over time ... What should I do then, when the attribute is a reserver word? I am going to be a grinch and note that this is strictly a usage question with no development implications. It therefore is off topic here and should have been asked and answered on python-list or the mirrored newsgroup. That's a misuse of attributes. When you need objects with unconstrained fields, inherit them from "dict", and write print(elem['param']) Right ;-) -- Terry Jan Reedy ___ 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] Python-dev signal-to-noise processing question
On 7/22/2010 3:29 PM, average wrote: Speacking of etiquette, it is traditional to use real names in the from field on pydev. It will get you more attention and respect. A reference or link to ESR's "How to Ask Questions The Smart Way" (http://catb.org/esr/faqs/smart-questions.html) is a pretty good inclusion also. For those who may have never heard of it, it's pretty much the authority on developer list etiquette. I agree Marcos Well, that is a start ;-) -- Terry Jan Reedy ___ 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] Set the namespace free!
> Date: Thu, 22 Jul 2010 14:49:17 -0400 > Subject: Re: [Python-Dev] Set the namespace free! > From: [email protected] > To: [email protected] > CC: [email protected] > > On Thu, Jul 22, 2010 at 12:53 PM, wrote: > .. > > So, ::name or &name or |name or whatever. > > > > I'm very amused by all the jokes about turning python into perl, but there's > > a good idea here that doesn't actually require that... > > No, there isn't. And both '&' and '|' are valid python operators that > cannot be used this way. > Um, of course. Serious brain freeze today, using too many languages at once. Yeah, that's it. Despite my knuckleheadedness, I say there's still a hole here that can be easily plugged. it's clumsy that you can't call, e.g. GenerateURL( reqtype='basic', class='local') other than by GenerateURL( **{'reqtype': 'basic', 'class': 'local'}) ... just because 'class' is a keyword. That's letting a parser issue degrade the value of a really good feature. Likewise for attributes; python allows you to have named parameters or attributes called 'class' and 'import' if you like; it just doesn't let you write them directly; this restriction doesn't seem to be necessary except for the parse issue, which is fixable. I.e. nothing would break by allowing GenerateURL(::class = 'local') orRequest.::class. See my previous longer post for the full discussion (not the short stupid one). ___ 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] New regex module for 3.2?
On Fri, Jul 23, 2010 at 12:42 AM, Georg Brandl wrote: > Sure -- I don't think this is a showstopper for regex. However if we don't > include regex in a future version, we might think about increasing MAXCACHE > a bit, and maybe not clear the cache when it reaches its max length, but > rather remove another element. Yikes, I didn't know it did that. That certainly sounds like it should be an RFE in its own right - some basic form of Least Recently Used accounting should be beneficial (although the extra bookkeeping might hurt scripts that aren't hitting the cache limit). 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
Re: [Python-Dev] Python-dev signal-to-noise processing question
On 7/22/2010 8:22 AM, Steven D'Aprano wrote: On Thu, 22 Jul 2010 07:02:33 pm Stephen J. Turnbull wrote: OTOH I think as quick as possible an answer is a good idea here. It saves the intended audience the thought about whether to reply or not, and an instant, constructive answer says that somebody cares. +1 Ditto. The sooner a person redirects a question to python-list, the sooner I will answer if I have an answer. And I do answer a lot of questions on Py-list, especially those that have sat a few hours without an answer. I think that waiting "a day or two" as suggested by Average does nobody any good. The only 'waiting' by anyone should be a few days by someone who posts on pylist *before* they try here for other expers. -- Terry Jan Reedy ___ 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] :program: markup in .rst documentation
On Fri, Jul 23, 2010 at 2:25 AM, Alexander Belopolsky wrote: > Note also that argparse/optparse does not know about -m way either: > > $ python -m profile -h > Usage: profile.py [-o output_file_path] [-s sort] scriptfile [arg] ... > > I am not sure if it is possible for argparse to distinguish between -m > and file name invocations, so maybe it should always use python -m > modname if sys.argv[0] ends with .py. Again, this is quite important > if the module being run is inside a package. If __main__.__package__ is set to anything other than None, odds are fairly good that runpy did the import. If it's set to a non-empty string, you definitely *shouldn't* be invoking the relevant main script by filename. Sounds like one for the tracker. 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
Re: [Python-Dev] Does trace modules have a unit test?
On Fri, Jul 23, 2010 at 3:30 AM, Alexander Belopolsky wrote: > I see three solutions: > > 1. Minimal: do not rename test_trace in 2.7 and add trace module > tests to the existing file. Whether to revert test_trace to > test_line_tracing renaming in 3.2 can be decided after we have 2.7 > tests written. > 2. Rename test_trace in 2.7/3.1 and test_line_tracing in 3.2 to > test_sys_settrace. > 3. Rename test_trace in 2.7/3.1 to test_line_tracing. > > My preference in #2, but I can live with #1 (assuming Eli is the one > who will write the tests:-). I'd say just fix it and go with #2 (just update the comment in test_sys as well!) 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
Re: [Python-Dev] Python-dev signal-to-noise processing question
On 22/07/2010 23:25, Terry Reedy wrote: On 7/22/2010 8:22 AM, Steven D'Aprano wrote: On Thu, 22 Jul 2010 07:02:33 pm Stephen J. Turnbull wrote: OTOH I think as quick as possible an answer is a good idea here. It saves the intended audience the thought about whether to reply or not, and an instant, constructive answer says that somebody cares. +1 Ditto. The sooner a person redirects a question to python-list, the sooner I will answer if I have an answer. And I do answer a lot of questions on Py-list, especially those that have sat a few hours without an answer. I think that waiting "a day or two" as suggested by Average does nobody any good. The only 'waiting' by anyone should be a few days by someone who posts on pylist *before* they try here for other expers. If only the same principal applied on the issue tracker. Anyone fancy taking on a few orphans, allowing for the fact that you might get told off for creating noise or for offending devs who don't like being reminded of outstanding issues? Still, what's nine years to someone who's waiting for a bug fix? Kindest regards. Mark Lawrence. ___ 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] Set the namespace free!
Am 22.07.2010 21:49, schrieb Reid Kleckner: > On Thu, Jul 22, 2010 at 11:49 AM, Alexander Belopolsky > wrote: >> On Thu, Jul 22, 2010 at 12:53 PM, wrote: >>> I'm very amused by all the jokes about turning python into perl, but there's >>> a good idea here that doesn't actually require that... >> >> No, there isn't. And both '&' and '|' are valid python operators that >> cannot be used this way. >> >> If you want ::, I think you can find a language or two to your liking. :-) > > A syntax for escaping reserved words used as identifiers is a worthy > and interesting idea, but I don't think it's worth adding to Python. Exactly. Such a feature is much more needed for languages that don't feature globals(), getattr() and __dict__s. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Python-dev signal-to-noise processing question
Steven D'Aprano writes: > We don't need to make excuses for why we don't give the answer here. > It's enough to give the reason -- it's off-topic for this list, which > is about the development of Python. That and a pointer to the right > list is, in my opinion, all we need to say. We don't need to sugar > coat it -- we're all adults here. That's fine for people who already feel they are part of this particular community. The concern, as I understand it from earlier in the thread, is the regular only-one-opportunity-at-a-first-impression response given to someone *new to* this community, who clearly doesn't yet know the mores and expectations. In that case, it's not enough to say “we're all adults”, because we're also all human: the perceived tone of a first response we receive will strongly influence our impression of the wider community, despite any appeals one might make to the irrationality of that reaction. Asking about how Python works is a likely first step to becoming a valuable contributor later on (even if most such steps never go beyond the first), and a poor impression will surely kill most of that potential. So I do think it's worth this discussion about how to achieve the conflicting goals already mentioned — efficient communication and welcome to newcomers — and that “we don't need to sugar coat it” is incorrect for this purpose. -- \ “Working out the social politics of who you can trust and why | `\ is, quite literally, what a very large part of our brain has | _o__) evolved to do.” —Douglas Adams | Ben Finney ___ 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] Set the namespace free!
On 23/07/10 04:24, [email protected] wrote: I've suggested :name, which doesn't break old code, I'm not so sure about that. Consider foo[a::b] Do you parse that as a 3-element slice, or as a 2-element slice with :b as the second element? -- Greg ___ 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] module shutdown procedure
Georg Brandl wrote: > Am 22.07.2010 13:29, schrieb Antoine Pitrou: >> Is it the reason why? With the new module creation API in 3.x, extension >> modules should be able to handle deletion of their own internal >> resources. > > Yes, but as Martin noted at the summit, nobody since went through all the > extension modules and changed them to use a struct instead of globals. And that's a necessary but likely not sufficient condition for the GC based module shutdown scheme to work. It really would take a huge amount of effort to make the idea fly. That doesn't mean it is not worth doing. The current scheme is pretty ugly. Neil ___ 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] Python-dev signal-to-noise processing question
On Fri, 23 Jul 2010 10:59:32 am Ben Finney wrote: > Steven D'Aprano writes: > > We don't need to make excuses for why we don't give the answer > > here. It's enough to give the reason -- it's off-topic for this > > list, which is about the development of Python. That and a pointer > > to the right list is, in my opinion, all we need to say. We don't > > need to sugar coat it -- we're all adults here. > > That's fine for people who already feel they are part of this > particular community. The concern, as I understand it from earlier in > the thread, is the regular only-one-opportunity-at-a-first-impression > response given to someone *new to* this community, who clearly > doesn't yet know the mores and expectations. I'm not suggesting that we need to be rude. But we can give them the respect of starting off by treating them according to the mores and expectations of our community, rather than by assuming that they will immediately take offence or be frightened off, or by immediately getting defensive about the fact that this isn't a beginner's list. We have nothing to be ashamed of for wanting to keep this list for dev related issues, why make excuses for it? In other words, keep doing what we've been doing for as long as I've been subscribed to this list: answer politely but firmly that this is the wrong list, point them to the correct place, and, if the mood strikes you, give a brief answer to the question that doesn't invite a long discussion. I think that's fair and respectful. -- 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] Python Language Summit EuroPython 2010
Maciej Fijalkowski, 22.07.2010 10:43: On Thu, Jul 22, 2010 at 9:51 AM, Brett Cannon wrote: Basically the whole setting a module's globals to None was done before gc came into the language. Now that it's there it seems that it might work to simply let gc clean up the module itself. But this brings in the question of how to order calling finalizers. It seemed the room had no specific answer other than it might just have to be near random as figuring out a reasonable order is hard. If you have a cycle, there is no other way than breaking it at random, right? This is where reference counting is pretty handy. It allows users to deliberately increase the reference count of certain objects that they want to stay alive longer than their own object, so that the GC cannot just collect them before they call the opposite decref in your finaliser. This obviously requires taking care that the objects you manipulate here cannot create reference-cycles themselves, but given that, it helped me fix a lot of hard to track down crashes in lxml. Stefan ___ 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] module shutdown procedure
Georg Brandl, 22.07.2010 16:13: Am 22.07.2010 13:29, schrieb Antoine Pitrou: Le jeudi 22 juillet 2010 à 07:23 -0500, Benjamin Peterson a écrit : 2010/7/22 Antoine Pitrou: Brett Cannon wrote: Basically the whole setting a module's globals to None was done before gc came into the language. Now that it's there it seems that it might work to simply let gc clean up the module itself. There is a patch at http://bugs.python.org/issue812369 for GC-based module shutdown, but it doesn't actually remove the setting of module globals to None. I think further testing and experimentation would be required to validate it. Also, it seems to have been stalled by static globals in extension modules that the gc doesn't know about. Is it the reason why? With the new module creation API in 3.x, extension modules should be able to handle deletion of their own internal resources. Yes, but as Martin noted at the summit, nobody since went through all the extension modules and changed them to use a struct instead of globals. The Cython project has had this on the agenda ever since the early days of 3.0, but we never got around to investing the time. http://trac.cython.org/cython_trac/ticket/173 http://trac.cython.org/cython_trac/ticket/218 We already generate optional module cleanup code as an atexit function to help with valgrind, so much of the code required for m_clear() is already there, but getting it right (i.e. making all module globals local to an instance) would require some effort on our side that is not currently considered worth it (just ask yourself what you want first: blazingly fast generator functions? Or Py3-only module cleanup code?). It wouldn't be hard to do, though, and adapting Cython here would immediately migrate a whole bunch of extension modules to the new module handling API. Note that this may not mean that all of these modules will work out of the box. The current cleanup code is disabled by default because module globals can be used in finalisers, which means that the module cleanup can crash if the globals are cleaned up in the wrong order. This could be worked around, though, as we could potentially detect required globals at compile time and either change the order of their cleanup or emit a warning that there is no such order in the face of cycles. So, as always, it's all just a matter of investing the time to get this implemented. Stefan ___ 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] Inline caching for method calls
Hi, Stefan Brunthaler started a thread on python-dev about a couple of patches he has written for CPython as part of his PhD. It seems that he has implemented inline caching for CPython. http://comments.gmane.org/gmane.comp.python.devel/115362 http://en.wikipedia.org/wiki/Inline_caching Something like this might be interesting for Cython, too. He hasn't published the patches yet, but they might well be worth a look when he does. Stefan ___ 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] Sorry, wrong list, please ignore - Re: Inline caching for method calls
Sorry, this should have gone to cython-dev, not python-dev ... ___ 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] Python 3 optimizations...
Hi, stefan brunthaler, 22.07.2010 13:22: during the last year, I have developed a couple of quickening-based optimizations for the Python 3.1 interpreter. As part of my PhD programme, I have published a first technique that combines quickening with inline caching at this year's ECOOP, and subsequently extended this technique to optimize several load instructions as well as eliminate redundant reference counting operations from instructions, which has been accepted for publication for an upcoming conference. [...] I wonder whether you would be interested in integrating these optimizations with the Python 3 distribution, hence this mail. I could send copies of the papers, as well as provide my prototype source code to interested members of the python development community. I'm absolutely interested, although not for the CPython project but for Cython. I wonder how you do inline caching in Python if the methods of a type can be replaced by whatever at runtime. Could you elaborate on that? Based on what information do you switch between inlining states? Or do you restrict yourself to builtin types? That might be worth it already, just think of list.append(). We have an optimistic optimisation for object.append() in Cython that gives us massive speed-ups in loops that build lists, even if we don't know at compile time that we are dealing with lists. Stefan ___ 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] Python Language Summit EuroPython 2010
On Thu, Jul 22, 2010 at 6:50 PM, Eric Smith wrote:
> Thanks for writing this, Tim.
>
> On 7/21/10 11:11 AM, Tim Golden wrote:
>
>> The issue of a __format__ equivalent for bytes was also raised as was the
>> idea of object methods to render an object as string or bytes, which could
>> be used in the polymorphic functions above.
>
> Does this mean bytes.__format__, or does it mean bytes.format?
> bytes.__format__ already exists, but it just calls object.__format__. I'm
> not sure what the desired functionality for bytes.__format__ would be.
>
> If it means bytes.format, this would be relatively easy to do in CPython, if
> there's agreement to add it.
Indeed, we meant b'...{}...{}...'.format(x, y). The problem is that it
can't invoke x.__format__() or y.__format__() since those will return
text strings instead of bytes. A proposed solution was to try
x.__bformat__() etc. Another proposed solution was to limit x and y to
a small set of common types and hard-code their meanings (e.g.
numbers, bytes, and dates).
--
--Guido van Rossum (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] Python 3 optimizations...
Hi, I guess it would be a good idea to quickly outline my inline caching approach, so that we all have a basic understanding of how it works. If we take for instance the BINARY_ADD instruction, the interpreter evaluates the actual operand types and chooses the matching operation implementation at runtime, i.e., operands that are unicode strings will be concatenated via unicode_concatenate, for float operands on the other hand, the interpreter would end up invoking float_add via binary_op1. Now, a very efficient way to achieve purely interpretative inline caching is to quicken the type-generic BINARY_ADD instruction to a type-dependent FLOAT_ADD instruction (this technique, i.e., inline caching via quickening, is the primary contribution of my ECOOP paper). Hence, I have a very simple code generator, that generates type-dependent interpreter instructions in a pre-compile step of the interpreter, and uses runtime type information to quicken/rewrite instructions. Aside of the operators, I have implemented this quickening technique for FOR_ITER, COMPARE_OP and CALL_FUNCTION instructions. > I'm absolutely interested, although not for the CPython project but for > Cython. I wonder how you do inline caching in Python if the methods of a > type can be replaced by whatever at runtime. Could you elaborate on that? > Currently, I only provide optimized derivatives for several separate call targets, i.e., whether a call target is a C function with varargs, or a Python function/method--this already eliminates a lot of overhead from invoking call_function. Based on further quantitative analysis, I can easily provide inline cached derivatives of frequently called functions, such as some builtin primitives. > Based on what information do you switch between inlining states? > I have instrumented versions of some functions that allow me to make quickening decisions, such as binary_op1, do_richcompare, or call_function, where I can quicken instructions to an optimized, inline cached, instruction derivative. > Or do you restrict yourself to builtin types? > Currently, my approach provides optimized derivative instructions for the standard library, e.g., unicode strings, numerical objects, containers, and iterators. > That might be worth it > already, just think of list.append(). We have an optimistic optimisation for > object.append() in Cython that gives us massive speed-ups in loops that > build lists, even if we don't know at compile time that we are dealing with > lists. > Yes, that sounds like a reasonable thing to do. I could provide much more optimized derivatives based on application profiles, too. Since I use a simple code generator for generating the derivatives, it would also be possible to provide end-users with the means to analyze their apps and generate optimized instruction derivatives matching their profile. Regards, --stefan ___ 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
