Re: [Python-Dev] bytes / unicode
R. David Murray wrote: Having such a poly_str type would probably make my life easier. A thought on this poly_str type: perhaps it could be called "ascii", since that's what it would have to be restricted to, and have a'xxx' as a literal syntax for it, seeing as literals seem to be one of its main use cases. I also would like just vent a little frustration at having to use single-character-slice notation when I want to index a character in a string in my algorithms Thinking way outside the square, and probably the pale as well, maybe @ could be pressed into service as an infix operator, with s...@i being equivalent to s[i:i+1] -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes / unicode
On Mon, Jun 28, 2010 at 08:28:45PM +1200, Greg Ewing wrote: > A thought on this poly_str type: perhaps it could be > called "ascii", since that's what it would have to be > restricted to, and have > > a'xxx' > > as a literal syntax for it, seeing as literals seem to > be one of its main use cases. This seems like a good idea. > > Thinking way outside the square, and probably the pale > as well, maybe @ could be pressed into service as an > infix operator, with > > s...@i > > being equivalent to > > s[i:i+1] > And this is way beyond being intuitive. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes / unicode
On Mon, 28 Jun 2010 13:55:26 +0530, Senthil Kumaran wrote: > On Mon, Jun 28, 2010 at 08:28:45PM +1200, Greg Ewing wrote: > > Thinking way outside the square, and probably the pale > > as well, maybe @ could be pressed into service as an > > infix operator, with > > > > s...@i > > > > being equivalent to > > > > s[i:i+1] > > > > And this is way beyond being intuitive. Agreed, -1 on that. Like I said, I was just venting. The decision to have indexing bytes return an int is set in stone now and I just have to live with it. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
Brett Cannon wrote: > On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin wrote: >> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote: >>> On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin wrote: AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based systems (http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-AC_005fPROG_005fCC-842). If Python's configure.in sets an otherwise-empty CFLAGS to -g before calling AC_PROG_CC, AC_PROG_CC won't change it. Or we could just preserve the users CFLAGS setting across AC_PROG_CC regardless of whether it's set, to let the user set CFLAGS on the configure line without stomping any defaults. >>> >>> I think saving and restoring CFLAGS across AC_PROG_CC was attempted in >>> http://bugs.python.org/issue8211 . It turned out that it broke OS X >>> universal builds. >> >> Thanks for the link to the issue. http://bugs.python.org/issue8366 >> says Ronald Oussoren fixed the universal builds without reverting the >> CFLAGS propagation. >> >>> I'm not sure I understand the importance of allowing AC_PROG_CC to set >>> CFLAGS (if CFLAGS is undefined at the point of the AC_PROG_CC); can >>> someone give an example of why this is necessary? >> >> Marc-Andre's argument seems to be "it's possible that AC_PROG_CC adds >> other flags as well (it currently doesn't, but that may well change in >> future versions of autoconf)." That seems a little weak to constrain >> fixing actual problems today. If it ever adds more arguments, we'll >> need to inspect them anyway to see if they're more like -g or -O2 >> (wanted or harmful). Please see the discussion on the ticket for details. AC_PROG_CC provides the basic defaults for the CFLAGS compiler settings depending on which compiler is chosen/found: http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html > I went ahead and reverted the change, but it does seem like the build > environment could use a cleanup. Thanks and, indeed, the build system environment variable usage does need a cleanup. It's a larger project, though, and one that will likely break existing build setups. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 28 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK20 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes / unicode
On Mon, Jun 28, 2010 at 6:28 PM, Greg Ewing wrote: > R. David Murray wrote: > >> Having such a poly_str type would probably make my life easier. > > A thought on this poly_str type: perhaps it could be > called "ascii", since that's what it would have to be > restricted to, and have > > a'xxx' > > as a literal syntax for it, seeing as literals seem to > be one of its main use cases. One of the virtues of doing this as a helper type in a module somewhere (probably string) is that we can defer that kind of decision until later. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
On Mon, Jun 28, 2010 at 12:38 PM, M.-A. Lemburg wrote: >> On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin wrote: >>> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote: I'm not sure I understand the importance of allowing AC_PROG_CC to set CFLAGS (if CFLAGS is undefined at the point of the AC_PROG_CC); can someone give an example of why this is necessary? >>> >>> Marc-Andre's argument seems to be "it's possible that AC_PROG_CC adds >>> other flags as well (it currently doesn't, but that may well change in >>> future versions of autoconf)." That seems a little weak to constrain >>> fixing actual problems today. If it ever adds more arguments, we'll >>> need to inspect them anyway to see if they're more like -g or -O2 >>> (wanted or harmful). > > Please see the discussion on the ticket for details. Yes, I've done that. It's repeatedly asserted in that discussion that AC_PROG_CC should be allowed to initialize an otherwise empty CFLAGS, but nowhere in that discussion does it explain *why* this is desirable. What would be so bad about not allowing AC_PROG_CC to initialize CFLAGS? (E.g., by setting an otherwise empty CFLAGS to '-g' before the AC_PROG_CC invocation.) That would fix the issue of the unwanted -O2 flag that AC_PROG_CC otherwise adds. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
Mark Dickinson wrote: > On Mon, Jun 28, 2010 at 12:38 PM, M.-A. Lemburg wrote: >>> On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin wrote: On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote: > I'm not sure I understand the importance of allowing AC_PROG_CC to set > CFLAGS (if CFLAGS is undefined at the point of the AC_PROG_CC); can > someone give an example of why this is necessary? Marc-Andre's argument seems to be "it's possible that AC_PROG_CC adds other flags as well (it currently doesn't, but that may well change in future versions of autoconf)." That seems a little weak to constrain fixing actual problems today. If it ever adds more arguments, we'll need to inspect them anyway to see if they're more like -g or -O2 (wanted or harmful). >> >> Please see the discussion on the ticket for details. > > Yes, I've done that. It's repeatedly asserted in that discussion that > AC_PROG_CC should be allowed to initialize an otherwise empty CFLAGS, > but nowhere in that discussion does it explain *why* this is > desirable. What would be so bad about not allowing AC_PROG_CC to > initialize CFLAGS? (E.g., by setting an otherwise empty CFLAGS to > '-g' before the AC_PROG_CC invocation.) That would fix the issue of > the unwanted -O2 flag that AC_PROG_CC otherwise adds. Why do you think that the default -O2 is unwanted and how do you know whether the compiler accepts -g as option ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 28 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK20 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote: > Why do you think that the default -O2 is unwanted Because it can cause debug builds of Python to be built with optimization enabled, as we've already seen at least twice. > and how do you know > whether the compiler accepts -g as option ? I don't. It could easily be tested for, though. Alternatively, setting an empty CFLAGS to '-g' could be done just for gcc, since this is the only compiler for which AC_PROG_CC adds -O2. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
Mark Dickinson wrote: > On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote: >> Why do you think that the default -O2 is unwanted > > Because it can cause debug builds of Python to be built with > optimization enabled, as we've already seen at least twice. Then let me put it this way: How many Python users will compile Python in debug mode ? The point is that the default build of Python should use the correct production settings for the C compiler out of the box and that's what AC_PROG_CC is all about. I'm pretty sure that Python developers who want to use a debug build have enough code foo to get the -O2 turned into a -O0 either by adjust OPT and/or by providing their own CFLAGS env var. Also note that in some cases you may actually want to have a debug build with optimizations turned on, e.g. to track down a compiler optimization bug. >> and how do you know >> whether the compiler accepts -g as option ? > > I don't. It could easily be tested for, though. Alternatively, > setting an empty CFLAGS to '-g' could be done just for gcc, since this > is the only compiler for which AC_PROG_CC adds -O2. ... and then end up with default Python builds which don't have debug symbols available to track down core dumps, etc. ? AC_PROG_CC checks whether the compiler supports -g and always uses it in that case. The option is supported by more compilers than just GCC. E.g. IBM's xlC and Intel's icl compilers support that option as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 28 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK20 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
M.-A. Lemburg wrote: > Mark Dickinson wrote: >> On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote: >>> Why do you think that the default -O2 is unwanted >> >> Because it can cause debug builds of Python to be built with >> optimization enabled, as we've already seen at least twice. > > Then let me put it this way: > > How many Python users will compile Python in debug mode ? > > The point is that the default build of Python should use > the correct production settings for the C compiler out of > the box and that's what AC_PROG_CC is all about. > > I'm pretty sure that Python developers who want to use a > debug build have enough code foo to get the -O2 turned into a -O0 > either by adjust OPT and/or by providing their own CFLAGS env var. > > Also note that in some cases you may actually want to have > a debug build with optimizations turned on, e.g. to track down > a compiler optimization bug. > >>> and how do you know >>> whether the compiler accepts -g as option ? >> >> I don't. It could easily be tested for, though. Alternatively, >> setting an empty CFLAGS to '-g' could be done just for gcc, since this >> is the only compiler for which AC_PROG_CC adds -O2. > > ... and then end up with default Python builds which don't have > debug symbols available to track down core dumps, etc. ? > > AC_PROG_CC checks whether the compiler supports -g and always > uses it in that case. The option is supported by more compilers > than just GCC. E.g. IBM's xlC and Intel's icl compilers support > that option as well. Sorry, Intel's compiler is called "icc", not "icl": http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/mac/man/icc.txt IBM's compiler: http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/compiler/ref/ruoptlst.htm -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 28 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK20 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN]: "newthreading" - an approach to simplified thread usage, and a path to getting rid of the GIL
On Sun, Jun 27, 2010 at 9:33 PM, Gregory P. Smith wrote: > fyi - newthreading has been picked up by lwn. > http://lwn.net/Articles/393822/#Comments Do you know if any of the commenters is Nagle himself (and if so, which)? The discussion is hard to follow since the context of replies isn't always clear. There also seems to be a bunch of C++ thinking (and some knee-jerk responses by people who aren't actually all that familiar with Python) although I admit I don't have much of an intuition about memory models for fully free threading myself. It's a brave new world... --Guido -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
On Mon, Jun 28, 2010 at 4:28 PM, M.-A. Lemburg wrote: > Mark Dickinson wrote: >> On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote: >>> Why do you think that the default -O2 is unwanted >> >> Because it can cause debug builds of Python to be built with >> optimization enabled, as we've already seen at least twice. > > Then let me put it this way: > > How many Python users will compile Python in debug mode ? > > The point is that the default build of Python should use > the correct production settings for the C compiler out of > the box and that's what AC_PROG_CC is all about. > > I'm pretty sure that Python developers who want to use a > debug build have enough code foo to get the -O2 turned into a -O0 > either by adjust OPT and/or by providing their own CFLAGS env var. Shrug. Clearly someone at some point in the past thought it was a good idea to have --with-pydebug builds use -O0. If there's going to be a deliberate decision to drop that now, then that's fine with me. >> I don't. It could easily be tested for, though. Alternatively, >> setting an empty CFLAGS to '-g' could be done just for gcc, since this >> is the only compiler for which AC_PROG_CC adds -O2. > > ... and then end up with default Python builds which don't have > debug symbols available to track down core dumps, etc. ? No, I don't see how that follows. I was suggesting that *for gcc only*, an empty CFLAGS be set to '-g' before calling AC_PROG_CC. The *only* effect this would have would be that for gcc, if the user hasn't specified CFLAGS, then CFLAGS ends up being '-g' rather than '-g -O2' after the AC_PROG_CC call. But I'm really not looking for an argument here; I just wanted to understand why you thought AC_PROG_CC setting CFLAGS was important, and you've explained that. Thanks. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
Mark Dickinson wrote: > On Mon, Jun 28, 2010 at 4:28 PM, M.-A. Lemburg wrote: >> Mark Dickinson wrote: >>> On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote: Why do you think that the default -O2 is unwanted >>> >>> Because it can cause debug builds of Python to be built with >>> optimization enabled, as we've already seen at least twice. >> >> Then let me put it this way: >> >> How many Python users will compile Python in debug mode ? >> >> The point is that the default build of Python should use >> the correct production settings for the C compiler out of >> the box and that's what AC_PROG_CC is all about. >> >> I'm pretty sure that Python developers who want to use a >> debug build have enough code foo to get the -O2 turned into a -O0 >> either by adjust OPT and/or by providing their own CFLAGS env var. > > Shrug. Clearly someone at some point in the past thought it was a > good idea to have --with-pydebug builds use -O0. If there's going to > be a deliberate decision to drop that now, then that's fine with me. Ah right, the time machine again :-) OPT already uses -O0 if --with-pydebug is used and the compiler supports -g. Since OPT gets added after CFLAGS, the override already happens... >>> I don't. It could easily be tested for, though. Alternatively, >>> setting an empty CFLAGS to '-g' could be done just for gcc, since this >>> is the only compiler for which AC_PROG_CC adds -O2. >> >> ... and then end up with default Python builds which don't have >> debug symbols available to track down core dumps, etc. ? > > No, I don't see how that follows. I was suggesting that *for gcc > only*, an empty CFLAGS be set to '-g' before calling AC_PROG_CC. The > *only* effect this would have would be that for gcc, if the user > hasn't specified CFLAGS, then CFLAGS ends up being '-g' rather than > '-g -O2' after the AC_PROG_CC call. But I'm really not looking for an > argument here; I just wanted to understand why you thought AC_PROG_CC > setting CFLAGS was important, and you've explained that. Thanks. Sorry, that was a misunderstand on my part. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 28 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK20 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WPython 1.1 was released
It would be interesting to see benchmark diagrams inline on one page with overall summaries. I've posted a enhancement to http://code.google.com/p/unladen-swallow/issues/detail?id=145 if somebody is going to look at that. I wonder if 32bit version can bring more speedups? -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pickle security and remote logging
Hello, I need to send logging module output over the network. The module has everything to make this happen, except security. SocketHandler and DatagramHandler examples are using pickle module that is said to be insecure. SocketHandler and DatagramHandler docs should at least contain a warning about danger of exposing unpickling interfaces to insecure networks. pickle documentation mentions that it is possible to control what gets unpickled, but there is any no example or security analysis if the proposed solution will be secure. Is there any way to implement secure network logging? I do not care about data encryption - I just do not want my server exploited by malformed data. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Access a function
I am a very new to python and have a small question.. I have a function: set_time_at_next_pps(self, *args, **kwargs) but don't know how to use it... Askign for your help please. Cheers, Zoh -- View this message in context: http://old.nabble.com/Access-a-function-tp29008798p29008798.html Sent from the Python - python-dev mailing list archive at Nabble.com. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Access a function
On 28/06/2010 19:09, Zohair wrote: I am a very new to python and have a small question.. I have a function: set_time_at_next_pps(self, *args, **kwargs) but don't know how to use it... Askign for your help please. Hi Zoh, This mailing list is for the development *of* Python, not for questions about developing *with* Python. You should ask your question on a mailing list / newsgroup like python-list or python-tutor. python-list is available via google groups: https://groups.google.com/group/comp.lang.python/topics You haven't given enough information to answer the question however. The first argument 'self' means that the function is probably a method of a class, and should be called from a class instance. The *args / **kwargs means that the function can take any number of arguments or keyword arguments, which doesn't tell us anything about the function should be used. You can find out more on Python functions in the tutorial: http://docs.python.org/tutorial/controlflow.html#more-on-defining-functions All the best, Michael Foord Cheers, Zoh -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Access a function
Hello. We'are sorry but we cannot help you. This mailing list is to work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems using Python, please find another forum. Probably python-list (comp.lang.python) news group/mailing list is the best place. See http://www.python.org/community/lists/ for other lists/news groups/fora. Thank you for understanding. On Mon, Jun 28, 2010 at 11:09:35AM -0700, Zohair wrote: > > I am a very new to python and have a small question.. > > I have a function: > set_time_at_next_pps(self, *args, **kwargs) but don't know how to use it... > Askign for your help please. > > Cheers, > > Zoh > -- > View this message in context: > http://old.nabble.com/Access-a-function-tp29008798p29008798.html > Sent from the Python - python-dev mailing list archive at Nabble.com. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/phd%40phd.pp.ru Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How to spell PyInstance_NewRaw in py3k?
Issue #5180 [1] presented an interesting challenge: how to unpickle instances of old-style classes when a pickle created with 2.x is loaded in 3.x python? The problem is that pickle protocol requires that unpickled instances be created without calling the __init__ method. This is necessary because pickle file may not contain information about how __init__ method should be invoked. Instead, implementations are required to bypass __init__ and populate instance's __dict__ directly using data found in the pickle. Pure python implementation uses the following trick that happens to work in 3.x: class Empty: pass pickled = Empty() pickled.__class__ = Pickled This of course, creates a new-style class in 3.x, but if 3.x version of Pickled behaves similarly to its 2.x predecessor, it should work. The cPickle implementation, on the other hand uses 2.x C API which is not available in 3.x. Namely, the PyInstance_NewRaw function. In order to fix the bug described in issue #5180, I had to emulate PyInstance_NewRaw using type->tp_alloc. I considered an rejected the idea to use tp_new instead. [2] Is this the right way to proceed? The patch is attached to the issue. [3] [1] http://bugs.python.org/issue5180 [2] http://bugs.python.org/issue5180#msg108846 [3] http://bugs.python.org/file17792/issue5180.diff ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Access a function
Of course I concur with the two posters above me, but in order to advertise for my own shop... If you're stuck with a lot of newbie questions like these you might want to try #python (the IRC channel on irc.freenode.net). You're more likely to get quick successive responses there than on other media (which are more suitable for bigger, more complex questions). cheers Laurens ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN]: "newthreading" - an approach to simplified thread usage, and a path to getting rid of the GIL
I'm moving this thread to python-ideas, where it belongs. I've looked at the implementation code (even stepped through it with pdb!), read the sample/test code, and read the two papers on animats.com fairly closely (they have a lot of overlap, and the memory model described below seems copied verbatim from http://www.animats.com/papers/languages/pythonconcurrency.html version 0.8). Some reactions (trying to hide my responses to the details of the code): - First of all, I'm very happy to see radical ideas proposed, even if they are at present unrealistic. We need a big brainstorm to come up with ideas from which an eventual solution to the multicore problem might be chosen. (Jesse Noller's multiprocessing is another; Adam Olsen's work yet another, at a different end of the spectrum.) - The proposed new semantics (frozen objects, memory model, auto-freezing of globals, enforcement of naming conventions) are radically different from Python's current semantics. They will break every 3rd party library in many more ways than Python 3. This is not surprising given the goals of the proposal (and its roots in Adam Olsen's work) but places a huge roadblock for acceptance. I see no choice but to keep trying to come up with a compromise that is more palatable and compatible without throwing away all the advantages. As it now stands, the proposal might as well be a new and different language. - SynchronizedObject looks like a mixture of a Java synchronized class (a non-standard concept in Java but easily understood as a class all whose public methods are synchronized) and a condition variable (which has the same semantics of releasing the lock while waiting but without crawling the stack for other locks to release). It looks like the examples showing off SynchronizedObject could be implemented just as elegantly using a condition variable (and voluntary abstention from using shared mutable objects). - If the goal is to experiment with new control structures, I recommend decoupling them from the memory model and frozen objects, instead relying (as is traditional in Python) on programmer caution to avoid races. This would make it much easier to see how programmers respond to the new control structures. - You could add the freeze() function for voluntary use, and you could even add automatic wrapping of arguments and return values for certain classes using a class decorator or a metaclass, but the performance overhead makes this unlikely to win over many converts. I don't see much use for the "whole program freezing" done by the current prototype -- there are way too many backdoors in Python for the prototype approach to be anywhere near foolproof, and if we want a non-foolproof approach, voluntary constraint (and, in some cases, voluntary, i.e. explicit, wrapping of modules or classes) would work just as well. - For a larger-scale experiment with the new memory model and semantic restrictions (or would it be better to call them syntactic restrictions? -- after all they are about statically detectable properties like naming conventions) I recommend looking at PyPy, which has as one of its explicitly stated project goals easy experimentation with different object models. - I'm sure I've forgotten something, but I wanted to keep my impressions fresh. - Again, John, thanks for taking the time to come up with an implementation of your idea! --Guido On Sat, Jun 26, 2010 at 9:39 AM, John Nagle wrote: > On 6/26/2010 7:44 AM, Jesse Noller wrote: >> >> On Sat, Jun 26, 2010 at 9:29 AM, Michael Foord >> wrote: >>> >>> On 26/06/2010 07:11, John Nagle wrote: We have just released a proof-of-concept implementation of a new approach to thread management - "newthreading". > > > >>> The import * form is considered bad practise in *general* and >>> should not be recommended unless there is a good reason. > > I agree. I just did that to make the examples cleaner. > >>> however the introduction of free-threading in Python has not been >>> hampered by lack of synchronization primitives but by the >>> difficulty of changing the interpreter without unduly impacting >>> single threaded code. > > That's what I'm trying to address here. > >>> Providing an alternative garbage collection mechanism other than >>> reference counting would be a more interesting first-step as far as >>> I can see, as that removes the locking required around every access >>> to an object (which currently touches the reference count). >>> Introducing free-threading by *changing* the threading semantics >>> (so you can't share non-frozen objects between threads) would not >>> be acceptable. That comment is likely to be based on a >>> misunderstanding of your future intentions though. :-) > > This work comes out of a discussion a few of us had at a restaurant > in Palo Alto after a Stanford talk by the group at Facebook which > is building a JIT compiler for PHP. We were discussing how to > make threading both safe for the average
