Re: [Python-Dev] Embedded Python startup is slow

[Santoso Wijaya]

On Thu, Mar 24, 2011 at 9:18 AM, James Y Knight  wrote:

> On Mar 24, 2011, at 11:58 AM, bruce bushby wrote:
> > My main concern was that a freshly compiled Python attempts to open 168
> non-existent files before starting.
> >
> > I understand that an interpreted language is probably not the best choice
> for an embedded device (although it's very nice for prototyping) , Python
> really should know what exists after it's just been compiledie before
> any corrupting modules or other nonsense has been added.
> >
> > It appears it is hard coded to open these files regardless of any
> "configure" options.
> >
> > On my desktop pc, when I run the most simple "Hello World"  78% of
> the overall execution time is spent opening filesmost of which don't
> exist.
> >
> > Some form of "cache" would help the startup time on the "second go" .
> but arguably just a "band aid" covering a deeper problem.
>
> The deeper problem on your Desktop PC being that MS-Windows' file system
> calls are horrifically expensive for no good reason? :)
>
>
Be that as it may, Windows is a major platform Python runs on and is
supported for. Limitations and quirky behaviors of each platform should be
taken into account, IMHO. And if expensive system calls are some of them, we
should take them into consideration.

~/santa
___
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] Dict access with double-dot (syntactic sugar)

[Santoso Wijaya]

I just want to chip in that, as far as syntactic sugar go, `somedict:foo`
looks better than `somedict..foo`.

2c...

~/santa


On Thu, Mar 24, 2011 at 4:40 AM, Jameson Quinn wrote:

> "class attrdict" is a perennial dead-end for intermediate pythonistas who
> want to save 3 characters/5 keystrokes for item access. Other languages such
> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
> why not python? Well, there are a number of reasons why not, beginning with
> all the magic method names in python.
>
> But saving keystrokes is still a reasonable goal.
>
> So what about a compromise? Allow "somedict..foo", with two dots, to take
> that place. It still saves 2 characters (often 4 keystrokes; and I find even
> ', "[", or "]" harder to type than ".").
>
> The "foo" part would of course have to obey attribute/identifier naming
> rules. So there would be no shortcut for "somedict['$#!%']". But for any
> identifier-legal foo, the interpreter would just read ..foo as ['foo'].
>
> I would not be surprised if I'm not the first person to suggest this. If
> so, and there's already well-known reasons why this is a bad idea, I
> apologize. But if the only reason not to is "we never did it that way
> before" or "it would be too addictive, and so people would never want to use
> older python versions" or "headache for tools like pylint", I think we
> should do it.
>
> ___
> 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/santoso.wijaya%40gmail.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] cpython: bump ast version

[Santoso Wijaya]

A revision number is, indeed, local to the working repository. A changeset
ID, however is global.

>From Mercurial's documentation:

Revision numbers referring to changesets are very likely to be different in
another copy of a repository. Do not use them to talk about changesets with
other people. Use the changeset ID instead

See: http://mercurial.selenic.com/wiki/RevisionNumber

~/santa


On Sun, Mar 13, 2011 at 2:27 PM, Benjamin Peterson wrote:

> 2011/3/13 Antoine Pitrou :
> > On Sun, 13 Mar 2011 01:34:21 +0100
> > benjamin.peterson  wrote:
> >> http://hg.python.org/cpython/rev/52940f7f3726
> >> changeset:   68416:52940f7f3726
> >> user:Benjamin Peterson 
> >> date:Sat Mar 12 18:35:23 2011 -0600
> >> summary:
> >>   bump ast version
> >>
> >> files:
> >>   Python/Python-ast.c
> >>
> >> diff --git a/Python/Python-ast.c b/Python/Python-ast.c
> >> --- a/Python/Python-ast.c
> >> +++ b/Python/Python-ast.c
> >> @@ -2,7 +2,7 @@
> >>
> >>
> >>  /*
> >> -   __version__ 68409:c017695acf19.
> >> +   __version__ 68410:0daa6ba25d9b.
> >
> > Is the version number necessary? It is local to the repository of the
> > person regenerating the file, and therefore not very reliable (for
> > example, 68410 on hg.python.org points to
> > http://hg.python.org/cpython/rev/f757b3b79c2a).
> >
> > The changeset id should be sufficient.
>
> I thought people might be comparing based on version numbers.
>
>
>
> --
> Regards,
> Benjamin
> ___
> 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/santoso.wijaya%40gmail.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] Mercurial conversion repositories

[Santoso Wijaya]

>
> [...] publishing patches by referring to a remote repository,
>
rather than uploading the diff.
>

Is this a recommended workflow at this point, or should we generate/attach
patch files still? Both, for experimentation?

~/santa


On Fri, Mar 4, 2011 at 1:15 PM, "Martin v. Löwis" wrote:

> > As a mercurial user, I thank you for this effort! One question,
> > where/how do I send suggestion to what to add into .hgignore file? In
> > particular, I found these dynamically generated files after a build in
> > Windows (3.2) that probably should be entered as .hgignore entries:
>
> All patches should go to the bug tracker. If you host a clone somewhere,
> you could start publishing patches by referring to a remote repository,
> rather than uploading the diff. I'm curious how this DVCS thing works
> out for contributors.
>
> Regards,
> Martin
>
___
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] Mercurial conversion repositories

[Santoso Wijaya]

Hi,

As a mercurial user, I thank you for this effort! One question, where/how do
I send suggestion to what to add into .hgignore file? In particular, I found
these dynamically generated files after a build in Windows (3.2) that
probably should be entered as .hgignore entries:

? PC/python_nt_d.h
? PC/pythonnt_rc_d.h



~/santa


On Mon, Feb 28, 2011 at 1:10 PM, Antoine Pitrou  wrote:

> On Mon, 28 Feb 2011 16:07:48 -0500
> Barry Warsaw  wrote:
> > On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote:
> >
> > >On Mon, 28 Feb 2011 10:08:26 -0500
> > >Barry Warsaw  wrote:
> > >>
> > >> >BTW, I had not heard of hgeditor before, and wrote a small hg
> extension to
> > >> >do what you want (with HG: prefix :) before I saw that others had
> already
> > >> >replied with hgeditor.  The extension had 10 lines of code.
> > >>
> > >> We should find a place (i.e. repository) to stash these useful add-ons
> and
> > >> hacks so that all Python developers can find them.
> > >
> > >I think you can simply add them somewhere on the hg wiki:
> > >http://mercurial.selenic.com/wiki/
> > >and then link to the pages from our own wiki, or the developer's FAQ.
> >
> > If they're of general use to the hg community, sure.  Otherwise, it might
> be
> > good to have a place of our own for our own repository tools.
>
> Well, your diff-in-the-commit-editor-window is certainly not
> CPython-specific ;)
>
> Regards
>
> Antoine.
>
>
> ___
> 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/santoso.wijaya%40gmail.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] Mercurial conversion repositories

[Santoso Wijaya]

>From http://mercurial.selenic.com/wiki/Branch#Named_branches:

[...] a good rule of thumb is to use branch names sparingly and for rather
longer lived concepts like "release branches" (rel-1, rel-2, etc) and rather
not for short lived work of single developers

So I think named branches make sense here. Bookmarks are really for
potential branches, experimental features, for example, for easier
navigation for the developer's convenience. Named branches, on the other
hand, are better for posterity reasons.

~/santa


On Sat, Feb 26, 2011 at 10:40 AM, Daniel Stutzbach wrote:

> On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote:
>
>> There is no such thing as an "unnamed branch". What would "hg branches"
>> show? An empty space?
>>
>
> I understand now why I was confused.  I had previously read the sentence
> "Both Git and Mercurial support unnamed local branches." at
> http://mercurial.selenic.com/wiki/BranchingExplained
>
> But as I dig deeper, I see that there is only one unnamed branch, and it
> actually does have an implicit name: "default".
>
> It appears Mercurial supports at least three different kinds of branching:
> cloning (similar to Bazaar), bookmarks (similar to git), and named branches.
>  So a named branch can contain more than one branch.
>
> Were there reasons for going with named branches over bookmarks?  PEP 385
> discusses only cloning and named branches.  I'm just curious, not trying to
> start a long discussion. :-)
>
> --
>  Daniel Stutzbach
>
> ___
> 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/santoso.wijaya%40gmail.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] Mercurial conversion repositories

[Santoso Wijaya]

A Mercurial 'merge'  is simply a
creation of another changeset, which has two parents: the current tip of the
branch you're working on, and the changeset you are merging with.

~/santa


On Sat, Feb 26, 2011 at 10:23 AM, Barry Warsaw  wrote:

> On Feb 26, 2011, at 06:32 PM, Éric Araujo wrote:
>
> >>> Named branches are exclusive, they can't be a subset of each other ;)
> >
> >Actually, they can.  Take the example of the Mercurial repo itself. They
> >fix bugs in the stable branch and add features in default.  When they
> >merge stable into default and commit, default becomes a superset of
> >stable.  That is to say, someone pulling default also gets the
> >changesets from stable that are ancestors of the merge changset.  Or in
> >other words, if you check out default, you get all bug fixes from stable.
>
> That makes sense, but correct me if I'm wrong, it's the 'merge' operation
> that
> made this happen, right?  A merge essentially brings the changesets from
> one
> branch into another.
>
> -Barry
>
> ___
> 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/santoso.wijaya%40gmail.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] svn outage on Friday

[Santoso Wijaya]

Speaking of, what is the current status and timeline on the move to
Mercurial?

~/santa


On Tue, Feb 15, 2011 at 1:25 AM, Victor Stinner <
victor.stin...@haypocalc.com> wrote:

> Le mardi 15 février 2011 à 09:30 +0100, "Martin v. Löwis" a écrit :
> > I'm going to perform a Debian upgrade of svn.python.org on Friday,
> > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
> > that time. The outage shouldn't be longer than an hour.
>
> It's time to move to Mercurial! :-)
>
> Victor
>
> ___
> 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/santoso.wijaya%40gmail.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