Re: Eclipse IDE printing values automatically
On 29/01/2014 06:26, mick verdu wrote: I am using Pydev 2.8 on Eclipse IDE. It is printing some values that haven't been printed with print command. How to deal with this problem? There are some very smart people on this list, but unless you give them details of what you've tried and precisely what went wrong how can we help? What does your code look like? Are you debugging, running a file via CTRL+F11 and seeing the output on the Pydev console, what? Slight aside, why 2.8, 3.3.3 has just been released? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
ANN: Python Events Calendar - Now with Twitter feed
[Please help spread the word by forwarding to other relevant mailing lists, user groups, etc. world-wide; thanks :-)] ANNOUNCING Python Events Calendars - Now with Twitter feed maintained by the Python Software Foundation (PSF) and a group of volunteers INTRODUCTION As some of you may know, the PSF has put together a team of volunteers who are maintaining a central Python events calendar. We currently have two calendars in place: * Python Events Calendar - meant for conferences and larger gatherings focusing on Python or a related technology (in whole or in part) * Python User Group Calendar - meant for user group events and other smaller local events The calendars are displayed on http://pycon.org/ and in a smaller version in the sidebar of the http://python.org/ website. You can subscribe to the calendars using iCal and RSS feeds and also embed the calendar widgets on your sites. Please see our wiki page for details: https://wiki.python.org/moin/PythonEventsCalendar The calendars are open to the world-wide Python community, so you can have local user group events, as well as regional and international conference events added to the calendars. NEWS We have now created a Twitter feed for the calendars, which you can follow to get updates on all newly added events: https://twitter.com/pythonevents The tweets come with links to the event listings, which you can add to your own Google calendars with a single click. ADDING EVENTS If you want to have entries added to those calendars, please write to eve...@python.org and include the following information: * Name of the event * Type of the event (conference, bar camp, user group, etc) * Focus on Python and approximate size * URL * Location and country * Date and time (if relevant) For recurring events, please also include a description of the recurrence in a way that's compatible and supported by Google calendars. MORE INFORMATION More information on the calendars, the URLs, feed links, IDs, embedding, etc. is available on the wiki: https://wiki.python.org/moin/PythonEventsCalendar Enjoy, -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
Ned Batchelder writes: > On 1/28/14 2:19 AM, wxjmfa...@gmail.com wrote: >> Different, but a little bit related. The work >> which is done actually on the possibility (not >> implemented but alreay realized) to colorize (style") >> the different graphemes of a glyph is very interesting. >> >> Python with its absurd Flexible String Representation >> just become a no go for the kind of task. >> >> (Should not be too complicate to understand.) >> >> jmf >> > > JMF, seriously, stop it. You've convinced no one because you have no > convincing arguments. > > It's obnoxious to continue to make this claim. Stop it. Please. > > If you want to try to convince someone, convince me. Write to me > offline: n...@nedbatchelder.com > > -- > Ned Batchelder, http://nedbatchelder.com > I seriously think jmf has a mental disorder. So these reactions won't do anything useful. Just ignore. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Eclipse IDE printing values automatically
On Tue, 28 Jan 2014 22:26:56 -0800, mick verdu wrote: > I am using Pydev 2.8 on Eclipse IDE. It is printing some values that > haven't been printed with print command. How to deal with this problem? There's no print statement in the code you included to demonstrate the problem, which is probably why the data you expect to be printed isn't being printed. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Large Two Dimensional Array
On Tue, 28 Jan 2014 21:25:54 -0800, Ayushi Dalmia wrote: > Hello, > > I am trying to implement IBM Model 1. In that I need to create a matrix > of 5*5 with double values. Currently I am using dict of dict but > it is unable to support such high dimensions and hence gives memory > error. Any help in this regard will be useful. I understand that I > cannot store the matrix in the RAM but what is the most efficient way to > do this? This looks to me like a table with columns: word1 (varchar 20) | word2 (varchar 20) | connection (double) might be your best solution, but it's going a huge table (2G5 rows) The primary key is going to be the combination of all 3 columns (or possibly the combination of word1 and word2) and you want indexes on word1 and word2, which will slow down populating the table, but speed up searching it, and I assume that searching is going to be a much more frequent operation than populating. Also, creating a database has the additional advantage that next time you want to use the program for a conversion between two languages that you've previously built the data for, the data already exists in the database, so you don't need to build it again. I imagine you would have either one table for each language pair, or one table for each conversion (treating a->b and b->a as two separate conversions). I'm also guessing that varchar 20 is long enough to hold any of your 50,000 words in either language, that value might need adjusting otherwise. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] [RELEASED] Python 3.3.4 release candidate 1
Would you to accept fixes for http://bugs.python.org/issue20434 and http://bugs.python.org/issue20437 before 3.3.4 final? On Mon, Jan 27, 2014 at 9:36 AM, Georg Brandl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On behalf of the Python development team, I'm reasonably happy to announce the > Python 3.3.4 release candidate 1. > > Python 3.3.4 includes several security fixes and over 120 bug fixes compared > to > the Python 3.3.3 release. > > This release fully supports OS X 10.9 Mavericks. In particular, this release > fixes an issue that could cause previous versions of Python to crash when > typing > in interactive mode on OS X 10.9. > > Python 3.3 includes a range of improvements of the 3.x series, as well as > easier > porting between 2.x and 3.x. In total, almost 500 API items are new or > improved > in Python 3.3. For a more extensive list of changes in the 3.3 series, see > > http://docs.python.org/3.3/whatsnew/3.3.html > > and for the detailed changelog of 3.3.4, see > > http://docs.python.org/3.3/whatsnew/changelog.html > > To download Python 3.3.4 rc1 visit: > > http://www.python.org/download/releases/3.3.4/ > > This is a preview release, please report any bugs to > > http://bugs.python.org/ > > The final version is scheduled to be released in two weeks' time, on or about > the 10th of February. > > Enjoy! > > - -- > Georg Brandl, Release Manager > georg at python.org > (on behalf of the entire python-dev team and 3.3's contributors) > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlLmDI4ACgkQN9GcIYhpnLAr6wCePRbHF80k5goV4RUDBA5FfkwF > rLUAnRg0RpL/b6apv+Dt2/sgnUd3hTPA > =Z4Ss > -END PGP SIGNATURE- > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers -- Thanks, Andrew Svetlov -- https://mail.python.org/mailman/listinfo/python-list
pytz question: GMT vs. UTC
According ato the pytz doc (http://pytz.sourceforge.net/):
"‘UTC’ is Universal Time, also known as Greenwich Mean Time or GMT in
the United Kingdom."
If they are equal, why don't timezone objects created from those two
strings compare equal?
>>> pytz.timezone("UTC") == pytz.timezone("GMT")
False
(I'm revealing my complete ignorance of timezone manipulation by
asking this question.)
Thx,
Skip
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pyro4 - reading files
- Original Message - > Hello there. > > I am currently working on a project involving the use of Pyro4. > > I have a scenario. > > We have the pc named A, and a pc named B. > > On pc B lies a python script, that includes pyro, and a method for > reading files. > > On pc A, we create an instance to the pyro object on pc B. And we > call the method for reading files. > > I want to read a file that lies on pc B, from pc A using the method > of the pyro object i just created. > > Is it possible? > > Thank you. Hi, Yes, read http://pythonhosted.org/Pyro4/tutorials.html If you plan to transfer large files between PCS, make sure you read http://pythonhosted.org/Pyro4/tipstricks.html before, as other solutions may be better suited. JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On Thu, Jan 30, 2014 at 4:29 AM, Skip Montanaro wrote:
> According ato the pytz doc (http://pytz.sourceforge.net/):
>
> "‘UTC’ is Universal Time, also known as Greenwich Mean Time or GMT in
> the United Kingdom."
>
> If they are equal, why don't timezone objects created from those two
> strings compare equal?
>
pytz.timezone("UTC") == pytz.timezone("GMT")
> False
There are some technical differences between UTC and GMT, which almost
never come up, and which I very much doubt are significant here (does
pytz care about leap seconds?). But what I'm seeing - at least in the
version of pytz that I picked up by typing 'sudo pip install pytz' on
Debian Wheezy - is that the two are different types. UTC seems to be a
special case, while GMT is like the others. That may be why they're
not comparing equal, even though all operations might happen to
produce the same results.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
Skip Montanaro writes:
> According ato the pytz doc (http://pytz.sourceforge.net/):
>
> "‘UTC’ is Universal Time, also known as Greenwich Mean Time or GMT in
> the United Kingdom."
This is inaccurate, and I'd like to see it corrected in the
documentation. UTC is neither UT nor GMT.
GMT is not precisely defined, which makes it unsuitable for keeping
precise time in a computer system.
> If they are equal, why don't timezone objects created from those two
> strings compare equal?
>
> >>> pytz.timezone("UTC") == pytz.timezone("GMT")
> False
Python is correct, the timezones are not the same.
See https://en.wikipedia.org/wiki/Coordinated_Universal_Time> and
https://en.wikipedia.org/wiki/Greenwich_Mean_Time>. From the
former:
Saying "GMT" often implies either UTC or UT1 when used within
informal or casual contexts. In technical contexts, usage of "GMT"
is avoided; the unambiguous terminology "UTC" or "UT1" is preferred.
> (I'm revealing my complete ignorance of timezone manipulation by
> asking this question.)
Treat GMT like any other locale-specific timezone, and convert to/from
it as late/early as possible (like a locale-specific encoding).
Treat UTC as the canonical timezone for keeping all timestamp values in
(like Unicode for text).
--
\ “Reality must take precedence over public relations, for nature |
`\cannot be fooled.” —Richard P. Feynman |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On 2014-01-29, Skip Montanaro wrote: > According ato the pytz doc (http://pytz.sourceforge.net/): > > "UTC is Universal Time, also known as Greenwich Mean Time or GMT in > the United Kingdom." > > If they are equal, The question is _are_ they equal? There is an exact defintion for what "UTC" is, and there's another exact definition of what UT1 is (more about this later). Civil timezones are defined as offsets from UTC. It seems that "GMT" no longer has an exact definition (at least from a metrologist's perspective) can be used to mean either UTC or UT1. UTC and UT1 can differ by up to 1 second. Leap seconds are occasionally added to UTC to keep it from drifting more than 1 second from UT1. >From a metrology point of view, what was originally called "GMT" (solar time at 0 degrees longtitude) is now called "UT1". So some people rightly claim that "GMT" means UT1. But nobody actually _uses_ UT1 (except metrologists and astronomers). All civil time is based on UTC: the official time in Greenwich (except during BST) is not UT1, it's UTC. So some other people rightly claim that "GMT" refers to UTC. In a software libary context, I would say that GMT should mean UTC and they ought to be considered equal and should always produce identical results. In a metrology context, people saying "GMT" probably ought to be smacked across the knuckes with a 12-inch platinum-iridium ruler and asked to try again until they specify either UTC or UT1 (or some other precisely defined UT-flavor). http://en.wikipedia.org/wiki/Universal_Time -- Grant Edwards grant.b.edwardsYow! A dwarf is passing out at somewhere in Detroit! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.3.4 release candidate 1
29.01.14 18:55, Andrew Svetlov написав(ла): Would you to accept fixes for http://bugs.python.org/issue20434 and http://bugs.python.org/issue20437 before 3.3.4 final? And http://bugs.python.org/issue20440. -- https://mail.python.org/mailman/listinfo/python-list
Re: Eclipse IDE printing values automatically
Thanks for reply. I am running file via ctrl+F11 and seeing output on pyDev Console. My code has got nested dictionaries, lists and tuples. What you want to see? -- https://mail.python.org/mailman/listinfo/python-list
Re: Eclipse IDE printing values automatically
On 29/01/2014 20:23, mick verdu wrote: Thanks for reply. I am running file via ctrl+F11 and seeing output on pyDev Console. My code has got nested dictionaries, lists and tuples. What you want to see? Two things, code and context. See here for how to go about this http://sscce.org/ -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
UTC "timezone" causing brain explosions
Following up on my earlier note about UTC v. GMT, I am having some
trouble grokking attempts to convert a datetime into UTC. Consider
these three values:
>>> import pytz
>>> UTC = pytz.timezone("UTC")
>>> UTC
>>> LOCAL_TZ = pytz.timezone("America/Chicago")
>>> LOCAL_TZ
>>> now = datetime.datetime.now()
>>> now
datetime.datetime(2014, 1, 29, 15, 39, 35, 263666)
All well and good, right? The variable "now" is a naive datetime
object. I happen to be sitting in a chair in the city of Chicago, so
let's call it what it is, a datetime in the America/Chicago timezone:
>>> s = LOCAL_TZ.localize(now)
>>> s
datetime.datetime(2014, 1, 29, 15, 39, 35, 263666, tzinfo=)
That looks good to me. Now, let's normalize it to UTC:
>>> t = UTC.normalize(s)
>>> t
datetime.datetime(2014, 1, 29, 15, 39, 35, 263666, tzinfo=)
>>> t.hour
15
WTF? Why isn't the t.hour == 21?
Okay, let's see what GMT does for us:
>>> GMT = pytz.timezone("GMT")
>>> u = GMT.normalize(s)
>>> u
datetime.datetime(2014, 1, 29, 21, 39, 35, 263666, tzinfo=)
>>> u.hour
21
That looks correct, but I don't understand why I don't get hour==21
out of the UTC.normalize call. It's like it's a no-op.
Skip
--
https://mail.python.org/mailman/listinfo/python-list
Re: UTC "timezone" causing brain explosions
On 01/29/2014 01:52 PM, Skip Montanaro wrote:
Following up on my earlier note about UTC v. GMT, I am having some
trouble grokking attempts to convert a datetime into UTC.
Okay, let's see what GMT does for us:
GMT = pytz.timezone("GMT")
u = GMT.normalize(s)
u
datetime.datetime(2014, 1, 29, 21, 39, 35, 263666, tzinfo=)
u.hour
21
That looks correct, but I don't understand why I don't get hour==21
out of the UTC.normalize call. It's like it's a no-op.
Having not examined the code, I can't tell you why UTC is different. I can say
that .astimezone seems to work in all cases:
--> GMT
--> UTC
--> LOCAL_TZ = pytz.timezone("America/Los_Angeles")
--> now = datetime.datetime.now()
--> s = LOCAL_TZ.localize(now)
--> s
datetime.datetime(2014, 1, 29, 14, 9, 56, 494967, tzinfo=)
--> s.astimezone(UTC)
datetime.datetime(2014, 1, 29, 22, 9, 56, 494967, tzinfo=)
--> s.astimezone(GMT)
datetime.datetime(2014, 1, 29, 22, 9, 56, 494967, tzinfo=)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: UTC "timezone" causing brain explosions
Skip Montanaro writes:
> Following up on my earlier note about UTC v. GMT, I am having some
> trouble grokking attempts to convert a datetime into UTC.
For what it's worth, you're not alone. Time zones are a hairy beast to
manage, made all the more difficult because national politicians
continually fiddle with them which means they can't just be a built-in
part of the Python standard library.
> Consider these three values:
>
> >>> import pytz
> >>> UTC = pytz.timezone("UTC")
> >>> UTC
>
> >>> LOCAL_TZ = pytz.timezone("America/Chicago")
> >>> LOCAL_TZ
>
> >>> now = datetime.datetime.now()
> >>> now
> datetime.datetime(2014, 1, 29, 15, 39, 35, 263666)
>
> All well and good, right?
Not really :-) You avoid the pain if you never create naive datetime
values in the first place.
Instead, specify the timezone for the value you're creating::
>>> now = datetime.datetime.now(tz=LOCAL_TZ)
>>> now
datetime.datetime(2014, 1, 29, 16, 35, 7, 900526, tzinfo=)
That way the value will respond correctly to requests to convert it to
whatever timezone you specify::
>>> MELBOURNE = pytz.timezone("Australia/Melbourne")
>>> now.astimezone(MELBOURNE)
datetime.datetime(2014, 1, 30, 9, 35, 7, 900526, tzinfo=)
>>> now.astimezone(UTC)
datetime.datetime(2014, 1, 29, 22, 35, 7, 900526, tzinfo=)
>>> now.astimezone(LOCAL_TZ)
datetime.datetime(2014, 1, 29, 16, 35, 7, 900526, tzinfo=)
--
\ “We tend to scoff at the beliefs of the ancients. But we can't |
`\scoff at them personally, to their faces, and this is what |
_o__) annoys me.” —Jack Handey |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: UTC "timezone" causing brain explosions
On Wed, Jan 29, 2014 at 1:52 PM, Skip Montanaro wrote:
> Following up on my earlier note about UTC v. GMT, I am having some
> trouble grokking attempts to convert a datetime into UTC. Consider
> these three values:
>
import pytz
UTC = pytz.timezone("UTC")
LOCAL_TZ = pytz.timezone("America/Chicago")
LOCAL_TZ
>
now = datetime.datetime.now()
now
> datetime.datetime(2014, 1, 29, 15, 39, 35, 263666)
>
> All well and good, right? The variable "now" is a naive datetime
> object. I happen to be sitting in a chair in the city of Chicago, so
> let's call it what it is, a datetime in the America/Chicago timezone:
>
s = LOCAL_TZ.localize(now)
s
> datetime.datetime(2014, 1, 29, 15, 39, 35, 263666, tzinfo= 'America/Chicago' CST-1 day, 18:00:00 STD>)
>
> That looks good to me. Now, let's normalize it to UTC:
I don't think .normalize() doesn't do what you think it does; it's
related to timezones with DST.
I believe you want datetime.astimezone() instead.
t = UTC.normalize(s)
t
> datetime.datetime(2014, 1, 29, 15, 39, 35, 263666, tzinfo=)
t.hour
> 15
>
> WTF? Why isn't the t.hour == 21?
Because you didn't actually perform a proper timezone conversion:
>>> t = s.astimezone(UTC)
>>> t
datetime.datetime(2014, 1, 29, 21, 39, 35, 263666, tzinfo=)
>>> t.hour == 21
True
> That looks correct, but I don't understand why I don't get hour==21
> out of the UTC.normalize call. It's like it's a no-op.
It is indeed a no-op:
"You can take shortcuts when dealing with the UTC side of timezone
conversions. normalize() and localize() are not really necessary when
there are no daylight savings time transitions to deal with."
-- http://pytz.sourceforge.net
Cheers,
Chris
--
https://mail.python.org/mailman/listinfo/python-list
Python shell wont open IDLE or an exisiting .py files
I am on Windows 8, Python 3.3.4 and 3.3.3 and all previous versions exhibit the same problem on my Windows 8 PC. This problem occurred out of nowhere overnight. It was working fine for months until today. > I tried to open a file and nothing happened. If I tried to open a .py file > (any .py file) from an existing instance of IDLE, it briefly flashed up a > new window and then closed both the new window and the existing window > (normally it opens the requested in a new window leaving the existing window > untouched). > > If I launch the Python GUI it opens a Python Shell fine. But as soon as I > try to open a file (including a "new" file), it closes the Shell. > > I rebooted the machine. Same problem. > > I repaired the Python installation and rebooted. Same problem. > > I uninstalled Python. Rebooted. Deleted the Python33 directory entirely. > Rebooted. Installed Python. Rebooted. Same problem. > > Everything else on the system appears to be working just fine. > > Any ideas what the problem might be or how else I might go about fixing > things? Sent from Windows Mail-- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On Thu, Jan 30, 2014 at 11:17 AM, Dennis Lee Bieber wrote: > On Wed, 29 Jan 2014 19:02:53 + (UTC), Grant Edwards > declaimed the following: > > >>to be smacked across the knuckes with a 12-inch platinum-iridium ruler > > Under what temperature/pressure conditions is that ruler? STP, of course. And the smack must be administered in exactly 1G environment, to ensure proper impact. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On 2014-01-30 01:50, Dennis Lee Bieber wrote: On Thu, 30 Jan 2014 11:28:16 +1100, Chris Angelico declaimed the following: On Thu, Jan 30, 2014 at 11:17 AM, Dennis Lee Bieber wrote: On Wed, 29 Jan 2014 19:02:53 + (UTC), Grant Edwards declaimed the following: to be smacked across the knuckes with a 12-inch platinum-iridium ruler Under what temperature/pressure conditions is that ruler? STP, of course. And the smack must be administered in exactly 1G environment, to ensure proper impact. How cruel... I suspect the smack at 0degC is much more painful than one at room temperature It's the 21st century; you should be making use of Unicode: 0°C. -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On Thu, Jan 30, 2014 at 1:40 PM, MRAB wrote: >> How cruel... I suspect the smack at 0degC is much more painful >> than one >> at room temperature >> > It's the 21st century; you should be making use of Unicode: 0°C. I started to read that and thought you were going to advocate the use of 0°K... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open IDLE or an exisiting .py files
On 1/29/2014 6:26 PM, shangonich...@sbcglobal.net wrote: I am on Windows 8, Python 3.3.4 and 3.3.3 and all previous versions exhibit the same problem on my Windows 8 PC. This problem occurred out of nowhere overnight. It was working fine for months until today. Try the following, which I believe I said before. 1. Start the normal console interpreter 'Python (command interpreter)' in the Start Menu. 2. In the interpreter, type >>> import idlelib.idle 3. Open a file. If Idle quits, 4. If Idle quits, look in the console for an exception message. 5. If you do not understand it, *copy and paste the entire message* here. 6. If the Python console also closes, report here. > I tried to open a file and nothing happened. If I tried to open a .py file > (any .py file) from an existing instance of IDLE, it briefly flashed up a > new window and then closed both the new window and the existing window > (normally it opens the requested in a new window leaving the existing window > untouched). This much I understood. > If I launch the Python GUI it opens a Python Shell fine. But as soon as I > try to open a file (including a "new" file), it closes the Shell. This I do not. What is 'Python GUI'? What is 'Python Shell'? > I rebooted the machine. Same problem. > > I repaired the Python installation and rebooted. Same problem. > > I uninstalled Python. Rebooted. Deleted the Python33 directory entirely. > Rebooted. Installed Python. Rebooted. Same problem. > > Everything else on the system appears to be working just fine. > > Any ideas what the problem might be or how else I might go about fixing > things? Sent from Windows Mail -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open IDLE or an exisiting .py files
Terry Reedy writes: > On 1/29/2014 6:26 PM, shangonich...@sbcglobal.net wrote: > > > If I launch the Python GUI it opens a Python Shell fine. But as > > > soon as I try to open a file (including a "new" file), it closes > > > the Shell. > > This I do not. What is 'Python GUI'? What is 'Python Shell'? Those are (part of) the names of menu entries created by the Python installer for MS Windows. I am not sure exactly what programs they invoke. -- \ “… whoever claims any right that he is unwilling to accord to | `\ his fellow-men is dishonest and infamous.” —Robert G. | _o__) Ingersoll, _The Liberty of Man, Woman and Child_, 1877 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
Steven D'Aprano wrote: On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote: Why do we even need an "input" function anyway if all it is going to do is read from stdin? That's not all it does. For example, it handles backspacing, so that typing H E L O O BACKSPACE BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO". No, it doesn't -- that's handled at a lower level. Any other method of reading from stdin, as long as it hasn't been redirected away from the console, has the same behaviour. I typed some backspaces in the input to each of the following experiments, and they didn't end up in the data: >>> import sys >>> x = sys.stdin.readline() HELLO >>> x 'HELLO\n' >>> import os >>> f = os.fdopen(0) >>> y = f.readline() adsxx >>> y 'adsxx\n' So input() really is a pure convenience function. (That doesn't mean it's not worth having, though!) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Eclipse IDE printing values automatically
In <583ab407-7831-45d7-b15d-46b30a6cc...@googlegroups.com> mick verdu writes: > Thanks for reply. > I am running file via ctrl+F11 and seeing output on pyDev Console. > My code has got nested dictionaries, lists and tuples. What you want to see? One thing you could try is to track down exactly which line(s) are causing the unwanted output. Add some print statements to your code, say one print every fifty lines or so. Or perhaps just one print statement at the top of each function. Make each message different so you can tell them apart in the output. When the unwanted output appears, take note of which of your print statements appears above and below it. Then you can add more print statements in between those two, until you have narrowed down exactly what line of code is causing the output. Then, if you still can't tell why it is happening, post that line of code here and maybe we can help. Or, if your program is short enough, you can just post the whole thing here. Be sure to give an example of the unwanted output, and tell us exactly how the program is being executed. If the program uses input files, be sure to give us those too. -- John Gordon Imagine what it must be like for a real medical doctor to gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Try-except-finally paradox
I found something like this in a StackOverflow discussion.
>>> def paradox():
... try:
... raise Exception("Exception raised during try")
... except:
... print "Except after try"
... return True
... finally:
... print "Finally"
... return False
... return None
...
>>> return_val = paradox()
Except after try
Finally
>>> return_val
False
I understand most of this.
What I don't understand is why this returns False rather than True. Does the
finally short-circuit the return in the except block?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Try-except-finally paradox
On Jan 29, 2014 11:01 PM, "Jessica Ross" wrote:
>
> I found something like this in a StackOverflow discussion.
> >>> def paradox():
> ... try:
> ... raise Exception("Exception raised during try")
> ... except:
> ... print "Except after try"
> ... return True
> ... finally:
> ... print "Finally"
> ... return False
> ... return None
> ...
> >>> return_val = paradox()
> Except after try
> Finally
> >>> return_val
> False
>
> I understand most of this.
> What I don't understand is why this returns False rather than True. Does
the finally short-circuit the return in the except block?
The docs don't seem to specify what happens in this case, but this behavior
is intuitive to me. If the except suite had raised an exception instead of
returning, the return in the finally would suppress that. The generalized
rule appears to be that the control flow specification executed later
overrides the earlier.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Try-except-finally paradox
On 2014.01.29 23:56, Jessica Ross wrote:
> I found something like this in a StackOverflow discussion.
def paradox():
> ... try:
> ... raise Exception("Exception raised during try")
> ... except:
> ... print "Except after try"
> ... return True
> ... finally:
> ... print "Finally"
> ... return False
> ... return None
> ...
return_val = paradox()
> Except after try
> Finally
return_val
> False
>
> I understand most of this.
> What I don't understand is why this returns False rather than True. Does the
> finally short-circuit the return in the except block?
>
My guess would be that the interpreter doesn't let the finally block get
skipped under any circumstances, so the return value gets set to
True, but then it forces the finally block to be run before returning, which
changes the return value to False.
--
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 10.0
--
https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
Grant Edwards wrote: smacked across the knuckes with a 12-inch platinum-iridium ruler Imperial or Scottish inches? -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Try-except-finally paradox
Le jeudi 30 janvier 2014 06:56:16 UTC+1, Jessica Ross a écrit :
> I found something like this in a StackOverflow discussion.
>
> >>> def paradox():
>
> ... try:
>
> ... raise Exception("Exception raised during try")
>
> ... except:
>
> ... print "Except after try"
>
> ... return True
>
> ... finally:
>
> ... print "Finally"
>
> ... return False
>
> ... return None
>
> ...
>
> >>> return_val = paradox()
>
> Except after try
>
> Finally
>
> >>> return_val
>
> False
>
>
>
> I understand most of this.
>
> What I don't understand is why this returns False rather than True. Does the
> finally short-circuit the return in the except block?
The paradox is, in my mind, that the fct paradox() is
programmed to be paradoxal.
Compare with:
>>> def noparadox(i):
... try:
... a = 1 / i
... print('Process')
... except ZeroDivisionError:
... print("ZeroDivisionError")
... a = '?'
... except Exception:
... print("Exception")
... a = '?'
... finally:
... print("Finally")
... return a
...
>>> noparadox(2)
Process
Finally
0.5
>>> noparadox(0)
ZeroDivisionError
Finally
'?'
>>> noparadox('asdf')
Exception
Finally
'?'
>>>
jmf
--
https://mail.python.org/mailman/listinfo/python-list
