Re: [Python-Dev] VAX NaN evaluations
> The nice Python folks who were at SCALE in Los Angeles last year gave me a
> Python t-shirt for showing Python working on m68k and for suggesting that
> I'd get it working on VAX. With libffi support for VAX from Miod Vallat,
> this is now possible.
>
> However, when compiling Python, it seems that attempts to evaluate NaN are
> made in test_complex.py, test_complex_args.py, test_float.py and
> test_math.py (at least in 2.7.5 - I'm working on compiling 3.3.2 now).
>
> The short answer is to skip those tests on VAXen. The better answer is to
> patch any isnan functions to always return false on VAXen and patch any code
> which tries to parse, for instance, float("NaN") to use something uncommon,
> such as the largest representable number (const union __double_u __infinity
> = { { 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff } };) or something else
> equally rare.
I think you are asking for trouble here. As VAX floating point does
not appear to have hardware support for NaN, attempts to "emulate"
such could be potentially dangerous. If such software were running
life-support systems, for example, your decision to emulate it would
put you at fault for criminal negligence, whereas a failure simply due
to lack of implementation would be more benign incompetence. Probably
better for an exception to be thrown or other hard error.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
I think I spoke to soon on my earlier reply. If you have control over the whole system, you could *set* policy on behalf of a whole platform (like VAX) so you can "safely" use an otherwise non-normal set of bits to designate divide by zero (a negative sign bit with the rest all zeros, for example) or other NaNs. But then you should be on IEEE floating point committee and make these *universal* for the particular platform in question. Despite the debate from another thread, there's probably no wisdom in using other magical bit patterns (xDEADBEEF). -- MarkJ Tacoma, Washington ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
> We'd have to have one uncommor and two extremely unlikely events all happen
> simultaneously for your example to be of concern:
Understood. But when things run millions of times a second,
"extremely unlikely" things can happen more often that you wanted.
> Two, someone would have to decide to use Python with NaN testing /
> comparison code to run some sort of life-support system. I can't imagine
> anyone who isn't already horribly incompetent doing anything like this.
People incorporate third-party software, often unknowingly, trusting
the process and "system" even though it is almost always *completely*
informal and simply a community of good-hearted individuals.
> Three, that someone would have to want to run that code and that
> life-support system on a VAX (or other system which doesn't handle NaNs.
>
> While you make a point worth making, nobody is ever going to be at fault for
> criminal negligence for having implementation side-cases.
You *could* be right. I'm just saying what would be safe, legally and
morally speaking.
> If that were even
> possible, open source software would be litigated out of existence and
> everyone would be suing Microsoft for their monumental failures.
End-to-end open source software doesn't (generally) make any
guarantees ("without warrantees of any kind"), so there's little basis
to sue. As for MSFT, people have been suing Microsoft. Apparently,
they have good lawyers, and people are smart enough not to use their
software too much in mission-critical applications (although
apparently this has changed over the years).
> So you indirectly say that you think it'd be best to just skip the tests and
> leave it so tha any attempts to handle NaNs would dump core. Is that right?
That keeps your hands most safe, but again, I suggest you research the
IEEE standard to see if there's already a standard for VAX rather than
spinning your own home-brewed version, or join the IEEE committee and
make one.
--
MarkJ
Tacoma, Washington
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)
> Should stdlib code use assert at all? > > If user input can trigger an assert, then the code should raise a normal > exception that will not disappear with -OO. > > If the assert is testing program logic, then it seems that the test belongs > in the test file, in this case, test/test_datetime.py. For example, consider > the following (backwards) code. > > Is there any policy on use of assert in stdlib production code? It is my assertion that assert should only be used where a system-level problem would occur, where you cannot trap an error condition. -- MarkJ Tacoma, Washington ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, Feb 23, 2013 at 7:02 AM, Stefan Krah wrote: > eli.bendersky wrote: >> +Ordered comparisons between enumeration values are *not* supported. Enums >> are >> +not integers! I agree with your idea, but note you probably shouldn't call them e-num-erations, then. > Hmm. I think this limits interoperation with C libraries and prototyping > C code. Like I say, despite the lack of alignment with C, that this is the right way to go for a high-level language like Python. But I don't think it should be built-into the language. The bigger question is: what things should be comparable? and this is something that has not been settled. Nor do I believe it can be by the language. This is where I rather liked the old __cmp__ function, not only was it easier to implement, but I could define a comparison and it was clearer that I was doing so (within the class at least). 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] IDLE in the stdlib
On Wed, Mar 20, 2013 at 7:57 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > On Mar 20, 2013, at 12:38 PM, Barry Warsaw wrote: > > Right. Ultimately, I think IDLE should be a separate project entirely, > but I > guess there's push back against that too. > > > The most important feature of IDLE is that it ships with the standard > library. > Everyone who clicks on the Windows MSI on the python.org webpage > automatically has IDLE. That is why I frequently teach Python with IDLE. > > If this thread results in IDLE being ripped out of the standard > distribution, > then I would likely never use it again. > > +1, FWIW MarkJ ___ 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] IDLE in the stdlib
On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy wrote: > On 3/20/2013 12:41 PM, Eli Bendersky wrote: > > Personally, I think that IDLE reflects badly on Python in more ways than >> one. It's badly maintained, quirky and ugly. >> > > Ugly is subjective: by what standard and compared to what? > I might be jumping in late here, but... The *only* thing I find "ugly" about it is that it doesn't have a white-on-black color scheme. Look at any hacker console and you won't find a white screen. Otherwise its fine. Fixing that issue is simple, I can upload my color scheme if anyone wants. > It serves a very narrow set of uses, > > IDLE serves a very important "narrow use" purpose -- helping the plethora of beginning programmers. Anyone who wants to criticize it can slap themselves. Python attracts many beginners, and if you don't remember, installing a separate "fancy" editor was never on the priority list until several years later. Give me a break. > > and does it badly. > > Come on. It gets even a strong programmer 80% of the way to what he/she needs. And in any case, I think the interpreter environment is the place to keep the programmer's focus. That is the arena where the community has been and it's what has kept programming in Python fun. And although this goes against decades(?) of programming history, the future of programming, is not in the editor. The "editor-centric paradigm" has not created a community of re-usable code, despite all the promises. I'll argue that the *interpreter environment* will be the future and the editor will be relegated to a simple memory-saving device. Mark Tacoma, Washington ___ 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] IDLE in the stdlib
On Thu, Mar 21, 2013 at 2:31 PM, Oleg Broytman wrote: > On Thu, Mar 21, 2013 at 02:19:33PM -0700, Mark Janssen < > dreamingforw...@gmail.com> wrote: > > The *only* thing I find "ugly" about it is that it doesn't have a > > white-on-black color scheme. Look at any hacker console and you won't > find > > a white screen. > >Call me a bad hacker or not hacker at all -- I hate black > backgrounds. My windows are always black-on-lightgrey, sometimes on dark > grey, never black. I have been spending 16 hours a day at the screen for > last 25 years -- and never understood black background. Lol, funny. It takes energy to display a phosphor, but none for black. So I don't know how it could be harder for the eyes. Plus, it's "hacker nostalgia" for me, going back to assembler and BASIC on an Apple II. But I think this thread discussion happened decades ago. 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] IDLE in the stdlib
On Fri, Mar 22, 2013 at 2:48 AM, Antoine Pitrou wrote: > Le Thu, 21 Mar 2013 21:38:41 +0100, > Georg Brandl a écrit : > > > Am 21.03.2013 19:13, schrieb Antoine Pitrou: > > > On Wed, 20 Mar 2013 19:57:54 -0700 > > > Raymond Hettinger wrote: > > >> > > >> On Mar 20, 2013, at 12:38 PM, Barry Warsaw > > >> wrote: > > >> > > >> > Right. Ultimately, I think IDLE should be a separate project > > >> > entirely, but I guess there's push back against that too. > > >> > > >> The most important feature of IDLE is that it ships with the > > >> standard library. Everyone who clicks on the Windows MSI on the > > >> python.org webpage automatically has IDLE. That is why I > > >> frequently teach Python with IDLE. > > >> > > >> If this thread results in IDLE being ripped out of the standard > > >> distribution, then I would likely never use it again. > > > > > > Which says a lot about its usefulness, if the only reason you use > > > it is that it's bundled with the standard distribution. > > > > Just like a lot of the stdlib, it *gets* a lot of usefulness from > > being a battery. But just because there are better/more > > comprehensive/prettier replacements out there is not reason enough to > > remove standard libraries. > > That's a good point. I guess it's difficult for me to think of IDLE as > an actual library. > > It's not a library. It's an application that is bundled in the standard distribution. Mark Tacoma, Washington. ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/19/2013 10:48 AM, Guido van Rossum wrote: >> Anyway, if you're doing arithmetic on enums you're doing it wrong. > > Hmm, bitwise operations, even? I think it's rather pointless to do bitwise operations on python enums. We're not that close to the machine. MarkJ Tacoma, Washington ___ 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] Purpose of Doctests [Was: Best practices for Enum]
>> I'm hoping that core developers don't get caught-up in the "doctests are bad >> meme". >> >> Instead, we should be clear about their primary purpose which is to test >> the examples given in docstrings. >> In other words, doctests have a perfectly legitimate use case. > > But more than just one ;-) Another great use has nothing to do with > docstrings: using an entire file as "a doctest". This encourages > writing lots of text explaining what you're doing,. with snippets of > code interspersed to illustrate that the code really does behave in > the ways you've claimed. +1, very true. I think doctest excel in almost every way above UnitTests. I don't understand the popularity of UnitTests, except perhaps for GUI testing which doctest can't handle. I think people just aren't very *imaginative* about how to create good doctests that are *also* good documentation. That serves two very good purposes in one. How can you beat that? The issues of teardown and setup are fixable and even more beautifully solved with doctests -- just use the lexical scoping of the program to determine the execution environment for the doctests. > picking-your-poison-ly y'rs - tim Cheers, 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 if we didn't have repr?
> I have pondered it many times, although usually in the form "Why do we > need both str and repr?" Here's an idea: considering python objects are "stateful". Make a general, state-query operator: "?". Then the distinction is clear. >>> ?"This is a string" #Returns the contents of the string This is a string Then repr() is clearly the object "as it is" -- unstripped; i.e., not just it's state (or contents, or whatever). -- MarkJ Tacoma, Washington ___ 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] Purpose of Doctests [Was: Best practices for Enum]
>> * Doctests practically beg you to write your code first and then copy and >> paste terminal sessions - they're the enemy of TDD > > Of course , not , all the opposite . If the approach is understood > correctly then the first thing test author will do is to write the > code «expected» to get something done . When everything is ok with API > code style then write the code . Many problems in the API and > inconsistencies are thus detected early . Now all we need is a test() built-in, a companion to help() and we have the primo platform for doctest-code-test cycle for TDD and agile development. --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] doctest and pickle
> >>> from pickle import dumps, loads > >>> Fruit.tomato is loads(dumps(Fruit.tomato)) > True Why are you using is here instead of ==? You're making a circular loop using "is" -- MarkJ Tacoma, Washington ___ 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] doctest and pickle
On Fri, Jun 7, 2013 at 10:50 AM, Mark Janssen wrote: >> >>> from pickle import dumps, loads >> >>> Fruit.tomato is loads(dumps(Fruit.tomato)) >> True > > Why are you using is here instead of ==? You're making a circular > loop using "is" I should add that when you're serializing with pickle and then reloading, the objects should be seen as "essentially equivalent". This means that they are either byte-by-byte equivalent (not sure actually if Python actually guarantees this), or every element would still compare equal and that is what matters. -- MarkJ Tacoma, Washington ___ 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] doctest and pickle
>> Why are you using is here instead of ==? > > > I'm using `is` because I'm verifying that the instance returned by > `pickle.loads` is the exact same object as the instance fed into > `pickle.dumps`. Enum members should be singletons. I see now. That makes sense, but I don't think you'll be able to do that. "Supposed to be singletons" while at the same time you are holding two instances on the interpreter line. How are you going to manage that? -- MarkJ Tacoma, Washington ___ 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] End of the mystery "@README.txt Mercurial bug"
> It's like this. Whenever you use special characters in a file name, > you're asking for trouble. The shell and the OS have negotiate how to > interpret it. It bigger than git, and not a bug. Sorry, I meant mercurial, not git. -- MarkJ Tacoma, Washington ___ 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] End of the mystery "@README.txt Mercurial bug"
> One month ago, unit tests were added to IDLE (cool!) with a file > called @README.txt. The @ was used to see the name on top in a listing > of the directory. It's like this. Whenever you use special characters in a file name, you're asking for trouble. The shell and the OS have negotiate how to interpret it. It bigger than git, and not a bug. The issue is between the file system, the kernel, and the shell. > I also had the issue on 3 different computers, and so I reported the > issue upstream: > http://bz.selenic.com/show_bug.cgi?id=3954 Try it on different OS's on different machines (MacOS, Linux, Windows) . If my theory is right, it should be inconsistent across machines, but consistent within the same machine. -- MarkJ Tacoma, Washington ___ 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] PEP 455: TransformDict
Sorry I missed the original discussion, but isn't this a simple case of putting a decorator around the getitem method (to transform the input key) and a single line in the body of the setitem method, making this very easy adaptation of the existing dict class? Mark ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?
On Sat, Mar 19, 2011 at 12:59 PM, Raymond Hettinger wrote: > On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote: >> On Sat, 19 Mar 2011 09:25:07 -0500 >> s...@pobox.com wrote: >> >>> The dev guide says something about collapsing changesets. Is that >>> collapsing commits within a changeset or collapsing multiple changesets >>> (whatever that might be)? Do I need this for a trivial change? Can I just >>> push at this point? Once pushed, how does it get merged into the main >>> codebase? >> >> Sincerely, I would really recommend that you read a Mercurial tutorial. >> We could answer all your questions one by one but that wouldn't help you >> much if you don't understand the concepts. > > Skip is not alone on this one. I've been using Mercurial for a couple of > months now, have read multiple tutorials and whatnot, but am still not clear > on how to follow the devguide's suggested cross-branch workflow. > > The dance of pulling, merging, reverting, collapsing, resolving, null > merging, and rebasing cross-linked branches is somewhat more involved and > complex than covered in any of the tutorials I've seen. I think this will always be the case until someone develops a wiki-type code revision system along with a voting model. The most reliable and highest ranking code would be a nucleus whereupon all other revisions from other collaborators would revolve. Links between the revisions and the core would have "acceptance" requirements. All would be organized around this circular nucleus rather than attempt linearity (which not only requires a benevolent dictator, but that everyone agree so that forks do not create factions -- or worse, abandonment). That being said, it would be a radical adjustment to development style as there would no longer be a "canonical" or MAIN authority. But whatever, wanna help me built it? Marcos, pangaia.sf.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
On Thu, Apr 14, 2011 at 7:09 AM, Ricardo Kirkner wrote: > I recently stumbled upon an issue with a class in the mro chain not > calling super, therefore breaking the chain (ie, further base classes > along the chain didn't get called). > I understand it is currently a requirement that all classes that are > part of the mro chain behave and always call super. My question is, > shouldn't/wouldn't it be better, > if python took ownership of that part, and ensured all classes get > called, even if some class misbehaved? I get annoyed by this issue as well, in various forms. It seems like such a discussion would have been resolved by now in the multitude of OOP languages, but I have to say it is quite strange to me that there is no distinction made between IS-A relationship and HAS-A relationships with regard to the issue of Inheritence. Python, confusingly makes no syntactic distinction, and its semantic distinction (through MRO and programmer conventions) seems quite suboptimal and "special-cased". --No fault of anyone's, perhaps it is indeed an unresolved issue within Computer Science. It should be clear that IS-A inheritance is really trying to say (or should be) that the following set/class (of methods and attributes) is a *super-set* of its "parent" (--See how the OO lexicon is already confused and mixing metaphors?). In this case, manually calling super() is not only completely redundant but adds various confusions. With regard to inheritence, I too would like to see automatic calls to super classes in every case were there is a complete sClearly there is utility in the notion of a set-theoretic containment DISCARDING:: the points are moot and need finer granularity that only the pangaia model can fix. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
Argh! Sorry list. I meant to discard the post that was just sent. Please accept my humblest apologies... 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
[Python-Dev] [Python-ideas] matrix operations on dict :)
On Mon, Feb 6, 2012 at 6:12 PM, Steven D'Aprano wrote: > On Mon, Feb 06, 2012 at 09:01:29PM +0100, julien tayon wrote: > > Hello, > > > > Proposing vector operations on dict, and acknowledging there was an > > homeomorphism from rooted n-ary trees to dict, was inducing the > > possibility of making matrix of dict / trees. > > This seems interesting to me, but I don't see that they are important > enough to be built-in to dicts. [...] > > > Otherwise, this looks rather like a library of functions looking for a > use. It might help if you demonstrate what concrete problems this helps > you solve. > > I have the problem looking for this solution! The application for this functionality is in coding a fractal graph (or "multigraph" in the literature). This is the most powerful structure that Computer Science has ever conceived. If you look at the evolution of data structures in compsci, the fractal graph is the ultimate. From lists to trees to graphs to multigraphs. The latter elements can always encompass the former with only O(1) extra cost. It has the potential to encode *any* relationship from the very small to the very large (as well as across or *laterally*) in one unified structure. Optimize this one data structure and the whole standard library could be refactored and simplified by an order of magnitude. Not only that, it will pave the way for the "re-factored" internet that's being worked on which creates a content-centric Internet beyond the graph-level, hypertext internet. Believe, it will be awesome. Slowing down 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] Add a frozendict builtin type
On Thu, Mar 1, 2012 at 10:00 AM, Guido van Rossum wrote: > > I do know that I don't feel comfortable having a sandbox in the Python > standard library or even recommending a 3rd party sandboxing solution > -- if someone uses the sandbox to protect a critical resource, and a > hacker breaks out of the sandbox, the author of the sandbox may be > held responsible for more than they bargained for when they made it > open source. (Doesn't an open source license limit your > responsibility? Who knows. AFAIK this question has not gotten to court > yet. I wouldn't want to have to go to court over it.) > Since there's no way (even theoretical way) to completely secure anything (remember the DVD protection wars?), there's no way there should be any liability if reasonable diligence is performed to provide security where expected (which is probably calculable to some %-age of assets protected). It's like putting a lock on the door of your house -- you can't expect to be held liable is someone has a crowbar. Open sourcing code could be said to be a disclaimer on any liability as your letting people know that you've got nothing your trying to conceal. It's like a dog who plays dead: by being totally open you're actually more secure 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
[Python-Dev] PEP
On Thu, Feb 9, 2012 at 5:18 PM, Guido van Rossum wrote:
> A dictionary would (then) be a SET of these. (Voila! things have already
>> gotten simplified.)
>>
>
> Really? So {a:1, a:2} would be a dict of length 2?
>
Eventually, I also think this will seque and integrate nicely into Mark
>> Shannon's "shared-key dict" proposal (PEP 412).
>>
>>
I just noticed something in Guido's example. Something gives me a strange
feeling that using a variable as a key doesn't smell right. Presumably
Python just hashes the variable's id, or uses the id itself as the key, but
I wonder if anyone's noticed any problems with this, and whether the hash
collision problems could be solved by removing this?? Does anyone even
use this functionality -- of a *variable* (not a string) as a dict key?
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] [Visualpython-users] How VPython 6 differs from VPython 5
On Sun, Jan 13, 2013 at 1:15 AM, Bruce Sherwood wrote: > Here is detailed information on how VPython 6 differs from VPython 5, which > will be incorporated in the Help for upcoming releases of VPython 6. Note > that the fact that in a main program __name__ isn't '__main__' is an > unavoidable "feature", not a bug. That is, there doesn't seem to be a way to > make this work. Hi, Bruce. I think there are two ways of fixing this. One is to get down to the C language level, and share the C main() loop, which will percolate back up into the CPython loop. The other involves mending the split that I've been mentioning that happened over floating point between the VPython developers and the Python-dev group. Then perhaps Guido will accept VPython using/sharing the __main__ "loop". (I'm CC'ing him in this message.) So, either of these tracks should fix this problem. This is why I keep mentioning the important of healing that split between the parties arguing in the two camps. Perhaps Tim Peters will be able help bridge this gap. > Changes from VPython 5 > > The new version makes an essential change to the syntax of VPython programs. > Now, an animation loop MUST contain a rate or sleep statement, which limits > the number of loop iterations per second as before but also when appropriate > (about 30 times per second) updates the 3D scene and handles mouse and > keyboard events. Without a rate or sleep statement, the scene will not be > updated until and unless the loop is completed. I think this is perfectly acceptible and is just a necessary restriction wherefrom the OS *must* maintain ultimate control of I/O. Python sits in userspace surrounded by the larger computation environment, so this is only fair that an OS call is made so that it can keep things in "check". Naming it "sleep" is okay, but makes it sound more like a voluntary thing, and as you probably know, is the traditional name for relinquishng some control to the OS. (cf. Unix Systems Programming, Robbins, et al.) > You should use the new function sleep rather than time.sleep. The new > function periodically renders the scene and processes mouse events, making > it possible to continue using zoom and rotate, whereas time.sleep does not > do this. This is strange to me. I think this is where VPython must be ahead of the curve and not close enough to the Linux development communities. > For technical reasons, it is necessary for VPython 6 to do something rather > unusual. When you import visual (or vis), your own program is in turn > imported by the visual module. Again this is because of the faction that was created by in 200?, regarding the Vpython community vs. the python-dev. Really, this should be mended. Anyway, I hope that any of this made sense. Thanks for your help! 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] [Visualpython-users] How VPython 6 differs from VPython 5
On Sun, Jan 13, 2013 at 12:14 PM, Bruce Sherwood wrote: > For the record, I do not know of any evidence whatsoever for a supposed > "split" between the tiny VPython community and the huge Python community > concerning floating point variables. Nor do I see anything in Python that > needs to be "fixed". Well it was bit enough that the python community created a brand-new language construct called import __future__ -- something never considered before then and which actually changes the behavior of python unlike any other module. And perhaps I've just felt it more because I was a big proponent of both 3-d graphics as a way to keep python a draw for beginning programmers and also a big fan of scientific simulation. No one had anything near vpython back then. (But ultimately I need to stop mentioning this issue to this vpython list because it's really the Python group which need to get back in sync.) > The new (currently experimental) version of VPython based on wxPython must, > in order to run in a Cocoa environment on the Mac, make the interact loop be > the primary thread, with the user's Python calculations at worst a secondary > thread, which is the opposite of the older VPython, where the > interval-driven rendering thread was secondary to the user's calculations. > By the unusual stratagem of having VPython import the user's program it has > been possible to make this work, and at the same time greatly simplify the > C++ component of VPython by eliminating threading, with additional important > simplification from eliminating essentially all platform-dependent code > thanks to the multiplatform character of wxPython. The result is that nearly > all existing VPython programs will work without change, at the very small > cost of a few marginal cases requiring minor tweaking. I should alter the > documentation to make this important property of the new version more > salient. I need to analyze this more carefully before commenting further 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
[Python-Dev] [Visualpython-users] How VPython 6 differs from VPython 5
> Since this was copied to the Python-Dev list, I want to go on record as > stating firmly that there is no evidence whatsoever to substantiate claims > that there has ever been some kind of conflict between VPython and Python. My apologies, Bruce, I didn't mean for that second message to go to they python-dev mailing list (and sorry python-dev list... :). > Since __future__ was also mentioned, I'll take the opportunity to say that > I've been very impressed by the way the Python community has handled the > difficult 2->3 transition. For example, it has been a big help to the > educational uses of VPython that we could tell students simply to start with > "from __future__ import division, print_function", put parens around print > arguments, and thereby make it irrelevant whether they used Python 2 or > Python 3. Many thanks to the Python development community! Yes, it is/was relatively seemless *syntactically*, but it hasn't been seemless *semanticly*. from __future__ still does something very odd as far as the program language definition -- it modifies the way the interpreter interprets a syntactic construct -- a sort of meta-linguistic construct. 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
