Re: [Python-Dev] Looking for VCS usage scenarios
* Will a DVCS allow simpler operation as if we are still using a centralized system like CVS or Subversion? Yes and no. There is nothing to prevent a formal workflow like that in CVS/Subversion. However, the separation of commit into record push to authoritative leaves open the possibility of annoying glitches until you get used to it, and even then it's easy to forget to push or to forget that you've committed not-for-pushing stuff, etc, etc. In practice it is probably simpler to use a dVCS-specialized workflow like record push to candidate. Bazaar offers the same semantic if you want to use it. In practice, when you use bzr checkout to get a branch, it becomes bound to the remote branch. When you commit to a local bound branch, the change is automatically pushed to the server, including the needed locking semantics, so the workflow is pretty much the same as if it were a Subversion checkout (hence the command name). Branches can be freely bound and unbound without effort, if desired. In the team I work on we've been using this for a while for the authoritative branches. So it's a distributed workflow otherwise, but at the end of the life cycle of a branch, we merge and commit to a bound branch pretty much like committing a change to Subversion. -- Gustavo Niemeyer http://niemeyer.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] Looking for VCS usage scenarios
Trying to expand our buildbot infrastructure to accept patches to test out or some patch queue manager might be nice, but I want to be realistic with what we have now. That's why I am not worrying about this email feature; until I know that we will actually use it and have the manpower to implement it I consider it a perk that might never be used. It's all great to dream about the future and what could be, but that is far beyond just trying to get us to switch to a DVCS and is just icing on the cake. It's not an email feature. It's about bundling revisions in a way that may be cheaply sent or attached in any way wanted. It is useful in practice. Attachments to bugs, mails, and so on are not novelty nor optimization. Check out how many patches you have attached to the bug tracker. Now consider how better would it be if these patches carried history information which allowed them to be merged considering context, and carried logs, authorship information, and incremental history. -- Gustavo Niemeyer http://niemeyer.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] Looking for VCS usage scenarios
Hello Stephen, I haven't used Bazaar beyond bzr pull of Mailman once a week or so, so I don't dislike it. Things I have observed or have seen discussed on the bazaar mailing list that you might want to consider: (1) The UI is as baroque as git's, once you consider all the plugins and GUIs that are available. Lots of different workspace styles (ordinary branching, stacked branching, looms -- similar to quilts?, lightweight checkouts, ...) are supported with a corresponding increase in subcommand count and/or options. (2) New repo formats are added frequently, and taking advantage of new features often requires upgrading your repo format. So-called lightweight checkouts can be especially annoying as they involve leaving the history on the server, making distributed work problematic. Both arguments strike me as odd. Having the *option* to leave your history on the server shouldn't be a problem, right? The same goes for (1): having more ways to use the tool isn't exactly a problem. My understanding is that to deal fully with these problems, the Bazaar developers plan to change the repo file format. Some progress has been made, (small) quantitative improvements have been made, but AFAIK bzr still has bad worst-case performance for some common operations on moderately large repos (way smaller than the Linux kernel). How large? Which repositories? Which operations? Which version of Bazaar? I'm sorry for jumping up on this, but you've mentioned one specific issue, which is being looked at, and then have generalized here. Without naming the issues, it's really hard to discuss anything. It is true that Bazaar performance was much worse in the past, and it is true that it's being improved, and will continue to improve. In case Bazaar is a good deal for Python nowadays, it should only get better over time. -- Gustavo Niemeyer http://niemeyer.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] Looking for VCS usage scenarios
Since I have never seen that come up during Python's development I am going to leave it out. But I do see the benefit and how it might help with future work. Of course, that's entirely up to you. But it strikes me as an odd approach to the selection of scenarios for a tool whose intention is precisely to support new usage scenarios. As I mentioned in the doc, the first example allows for whatever the DVCS does for diffs, whether that is a full-on branch or not. Are you looking for new scenarios or for the validation of your document? :-) I'm talking about history-carrying diffs which can be attached and sent via mail, not about viewing plain diffs, which every VCS tool in the world can do since version 0.0. Anyway, I guess you already have what you want. Good luck picking the right choice! -- Gustavo Niemeyer http://niemeyer.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] Looking for VCS usage scenarios
Both. First and foremost I am looking for any scenarios people are using now for svn that I didn't cover. After that I can probably add some DVCS-specific things. But the problem with that is my DVCS experience is limited and thus I don't want to add a scenario that So try to listen to people that actually use these tools and are trying to help you. seems whizbang cool but in real life is never used; premature optimization and all that. As I mentioned early in my mail, all the scenarios I described were specifically meant to expose common situations that we go through in our workflow. I'm not picking weird things to try favoring any specific tool, even because I believe all tools should support these very basic desires. As I said, one of the scenarios already says patches can be whatever the DVCS supports the best; plain diffs, branches, etc. And the comments for that scenario will point out any perks from that feature. This scenario to meant to represent the steps required for a non-core developer who has a one-off patch they want to create from a read-only checkout. Ok, so would you mind to expand that to describe that the tool should send the history of the one-off patch, and what it means to not send it? Otherwise you're really comparing oranges and apples. If I send you svn diff or bzr diff, you get a plain diff. Merging this will not carry the history of who made the chances, what were the incremental steps, and will handle conflicts without context, which may be way more boring to perform than when you actually have full history information. That's not the same as using bzr send. Again, that's a real world situation, not something I'm making up to favor bzr. I'm pretty sure hg should have something similar too (and git does for sure). As for the via mail feature, I use Gmail so it doesn't mean anything to me. =) Please ask Tim to teach you how the mail word got in Gmail. ;-) -- Gustavo Niemeyer http://niemeyer.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] Looking for VCS usage scenarios
Hi Brett, At this point I am looking for any suggestions for fundamental usage scenarios that I am missing from the PEP. If you think the few already listed are missing some core part of a VCS, please let me know. As an initial disclaimer, I use bzr in my daily routine. That said, I'm sending below a few mostly unbiased high-level ideas, just based on useful ways we explore the DVCS-aspect on our normal daily workflow. == Coordinated development with dependent features == A variation on coordinated development, which is actually one of the main motivators for DVCS. Branch A is evolving out of the mainline, and it depends on a feature that is on branch B which is also not yet integrated. Parallel development of both should be nicely supported. I'm sure all DVCS will do that in a decent form, but figuring how this works may be instructive and worth mentioning. == Centralization of feature-specific development == That's a curious one when we're talking about distributed development, isn't it? :-) Think about the following scenario: 5 people working in parallel on a tricky feature which will take a while to get to the mainline. Each developer works on a specific aspect of the feature for a few hours/days in their own branch, and then merges to and from what's considered as the feature-mainline. In essence, the problem is that it's messy to just go towards the everyone merges from everyone route when working in a common problem. We've found that being able to use an svn-like approach for the *feature* mainline (a branch that is shared by all defining the status quo) is a handy way to handle that. I'm sure there are other approaches to solve the same problem, but it's interesting to consider what they are for each tool since in our experience the problem will show up eventually, and supporting it nicely makes a big difference on the outcome. == Attaching of history-carrying diffs == This one may feel weird as well, and I'm guessing some people might react as just send a URL to a branch. In practice, it is handy many times to just attach something to the bug tracker, for instance. This means that the branch is kept in the history of the bug. Also, with something like this, someone external to the development process may very easily provide his changes in the bug or in a mail without having to set up any infrastructure/accounts/whatever at all to provide his branch. That's it for now. If I can think of any other use cases from our routine that might serve as things to explore in such a comparison, I'll let you know. -- Gustavo Niemeyer http://niemeyer.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] Amusing fan mail I got
i thought about this thing. (...) +1! -- Gustavo Niemeyer http://niemeyer.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] Minipython
I would like to run Python scripts on an embedded MIPS Linux platform having only 2 MiB of flash ROM and 16 MiB of RAM for everything. (...) Have you looked at Python for S60 and Python for the Maemo platform? If not directly useful, they should provide some hints. [1] http://opensource.nokia.com/projects/pythonfors60/ [2] http://pymaemo.sf.net -- Gustavo Niemeyer http://niemeyer.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
[Python-Dev] dict.discard
Hey guys, After trying to use it a few times with no success :-), I'd like to include a new method, dict.discard, mirroring set.discard: print set.discard.__doc__ Remove an element from a set if it is a member. If the element is not a member, do nothing. Comments? -- Gustavo Niemeyer http://niemeyer.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] dict.discard
Would the argument be the key, or the pair? I'd guess the key.
Right, the key.
If so, there's the 2-arg flavor of dict.pop():
d = {}
d.pop(key, None)
It's not terribly obvious, but does the job without enlarging
the dict API.
Yeah, this looks good. I don't think I've ever used it like this.
--
Gustavo Niemeyer
http://niemeyer.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
[Python-Dev] buildbot breakage
Some buildbots will fail because they got revision r51793, and it has a change I made to fix a problem in the subprocess module. Please do not rollback any changes. I'm handling the issue. Also notice that there's no broken code there. The problem is that the issue in subprocess is related to stdout/stderr handling, and I'm having trouble making buildbot happy while keeping the new tests in place. I apologise for any inconvenience this may cause. -- Gustavo Niemeyer http://niemeyer.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] buildbot breakage
Some buildbots will fail because they got revision r51793, and it has a change I made to fix a problem in the subprocess module. I've removed the offending test in r51794 and buildbots should be happy again. One of the ways of exploring the issue reported is using sys.stdout as the stdout keyword, such as: subprocess.call([...], stdout=sys.stdout) it breaks because it ends up closing one of the standard descriptors of the subprocess. Unfortunately we can't test it that way because buildbot uses a StringIO in sys.stdout. I kept the test which uses stdout=1, and removed the one expecting sys.stdout to be a normal file. Sorry for the trouble, -- Gustavo Niemeyer http://niemeyer.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] no remaining issues blocking 2.5 release
Did you still want this addressed? Anthony and I made some comments on the bug/patch, but nothing has been updated. I was waiting because I got unassigned from the bug, so I thought the maintainer was stepping up. I'll commit a fix for it today. Thanks for pinging me, -- Gustavo Niemeyer http://niemeyer.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] no remaining issues blocking 2.5 release
If you have issues, respond ASAP! The release candidate is planned to be cut this Thursday/Friday. There are only a few more days before code freeze. A branch will be made when the release candidate is cut. I'd like to see problem #1531862 fixed. The bug is clear and the fix should be trivial. I can commit a fix tonight, if the subprocess module author/maintainer is unavailable to check it out. -- Gustavo Niemeyer http://niemeyer.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] Moving the ctypes repository to python.org
I think the best would be to import it into an url like http://svn.python.org/projects/sandbox/trunk/ctypes/ Is it possible to take the CVS repository files (they can be accessed with rsync), and import that, preserving the whole history, into SVN? It should be possible to use cvs2svn itself, creating a dump file, and loading that dump file into an existing repository with 'svnadmin load --parent-dir'. -- Gustavo Niemeyer http://niemeyer.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] Alternative path suggestion
The biggest conceptual change is that my path object is a subclass of
''tuple'', not a subclass of str. For example,
Using tuples is a nice idea! Object paths using tuples is a somewhat
common concept. I don't see an immediate reason to be a *subclass*
of tuple, though, as opposed to using it as an internal representation.
{{{
p.normpath() - Isn't needed - done by the constructor
p.basename() - p[-1]
p.splitpath() - (p[:-1], p[-1])
p.splitunc() - (p[0], p[1:]) (if isinstance(p[0], path.UNCRoot))
p.splitall() - Isn't needed
p.parent - p[:-1]
p.name- p[-1]
p.drive - p[0] (if isinstance(p[0], path.Drive))
p.uncshare- p[0] (if isinstance(p[0], path.UNCRoot))
and of course:
p.join(q) [or anything like it] - p + q
}}}
Nice indeed.
The only drawback I can see in using a logical representation is that
giving a path object to functions which expect a path string won't
work. The immediate solution is to simply use str(p) instead of p. The
long-term solution is to make all related functions accept a path
object.
Let's use __path_.. I mean, generic functions! ;-)
(...)
* A ''relative path'' is a path without a root element, so it can be
concatenated to other paths.
* An ''absolute path'' is a path whose meaning doesn't change when
the current working directory changes.
That sounds right.
== Easier attributes for stat objects ==
The current path objects includes:
* isdir, isfile, islink, and -
* atime, mtime, ctime, size.
(...)
This indeed shouldn't be attributes of path, IMO, since they are
operations that depend on the state of the filesystem, and will
change behind your back.
I think that isfile, isdir should be kept (along with lisfile,
lisdir), since I think that doing what they do is quite common, and
requires six lines:
I don't agree. isdir is an attribute of the filesystem, not of
the path object. I'd never expect that e.g. a network operation
could result from accessing an attribute in Python, and that could
certainly happen if the path is referencing a network filesystem.
--
Gustavo Niemeyer
http://niemeyer.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] Alternative path suggestion
You ought to have predefined classes for the standard OSes. Expecting people to know the values for sep and extsep seems unhelpful. (...) Why not something as simple as having path.sep == None meaning the default for the platform, and a defined value for otherwise? -- Gustavo Niemeyer http://niemeyer.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] setuptools in 2.5.
The arguments against: One more: - Installing a package means dropping files in the system without any kind of record keeping. It should learn from the techniques applied in other well-known package managers (RPM, DPKG, whatever) to keep track of what's happening in the system. -- Gustavo Niemeyer http://niemeyer.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] Updated: PEP 359: The make statement
Removing __metaclass__ in Python 3000 - As a side-effect of its generality, the make-statement mostly eliminates the need for the ``__metaclass__`` attribute in class objects. Thus in Python 3000, instead of:: (...) One of the reasons that this PEP was born is because metaclasses are being used in ways that don't look natural to some, like generating interface instances out of a class statement, so this would add an interesting way to support these constructs. That doesn't look like a good reason, though, to kill the metaclass support that Python took so long to maturate. Otherwise, a new optional extension could be included as well: Removing the 'class' statement. -- Gustavo Niemeyer http://niemeyer.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] Updated: PEP 359: The make statement
Consider it dead. =) RIP. ;) -- Gustavo Niemeyer http://niemeyer.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] Generalizing *args and **kwargs
I've been thinking about generalization of the *args/**kwargs syntax for quite a while, and even though I'm pretty sure Guido (and many people) will consider it overgeneralization, I am finally going to suggest it. This whole idea is not something dear to my heart, although I obviously would like to see it happen. If the general vote is 'no', I'll write a small PEP or add it to PEP 13 and be done with it. A PEP would be great, even if not accepted. At least we'll have it discussed in a single place and avoid rediscussing it everytime someone figures out it's a nice idea. Have a look for the subject Extending tuple unpacking in the mailing list for a recent discussion on the topic. -- Gustavo Niemeyer http://niemeyer.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
[Python-Dev] StreamHandler eating exceptions
The StreamHandler available under the logging package is currently catching all exceptions under the emit() method call. In the Handler.handleError() documentation it's mentioned that it's implemented like that because users do not care about errors in the logging system. I'd like to apply the following patch: Index: Lib/logging/__init__.py === --- Lib/logging/__init__.py (revision 41357) +++ Lib/logging/__init__.py (working copy) @@ -738,6 +738,8 @@ except UnicodeError: self.stream.write(fs % msg.encode(UTF-8)) self.flush() +except KeyboardInterrupt: +raise except: self.handleError(record) Anyone against the change? -- Gustavo Niemeyer http://niemeyer.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
[Python-Dev] Extending tuple unpacking
Not sure if this has been proposed before, but one thing I occasionally miss regarding tuple unpack is being able to do: first, second, *rest = something Also in for loops: for first, second, *rest in iterator: pass This seems to match the current meaning for starred variables in other contexts. What do you think? -- Gustavo Niemeyer http://niemeyer.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] Extending tuple unpacking
Someone should really write up a PEP -- this was just discussed a week or two ago. Heh.. I should follow the list more closely. I personally think this is adequately handled by writing: (first, second), rest = something[:2], something[2:] That's an alternative indeed. But the the proposed way does look better: for item in iterator: (first, second), rest = item[2:], item[:2] ... vs. for first, second, *rest in iterator: ... I believe that this wish is an example of hypergeneralization -- an incorrect generalization based on a misunderstanding of the underlying principle. Thanks for trying so hard to say in a nice way that this is not a good idea. :-) Argument lists are not tuples [*] and features of argument lists should not be confused with features of tuple unpackings. Do you agree that the concepts are related? For instance: def f(first, second, *rest): ... print first, second, rest ... f(1,2,3,4) 1 2 (3, 4) first, second, *rest = (1,2,3,4) print first, second, rest 1 2 (3, 4) [*] Proof: f(1) is equivalent to f(1,) even though (1) is an int but (1,) is a tuple. Extended *tuple* unpacking was a wrong subject indeed. This is general unpacking, since it's supposed to work with any sequence. -- Gustavo Niemeyer http://niemeyer.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
[Python-Dev] SIGPIPE = SIG_IGN?
Greetings,
I was wondering, why are we setting SIGPIPE to SIG_IGN
in initsigs():
static void
initsigs(void)
{
#ifdef SIGPIPE
PyOS_setsig(SIGPIPE, SIG_IGN);
#endif
[...]
}
One of the side effects is:
os.system(yes | read any)
yes: standard output: Broken pipe
yes: write error
0
os.system(yes | head -1)
y
yes: standard output: Broken pipe
yes: write error
0
That stops when setting to SIG_DFL:
signal.signal(signal.SIGPIPE, signal.SIG_DFL)
1
os.system(yes | head -1)
y
0
os.system(yes | read any)
0
Out of curiosity, many of the google results for
yes: standard output: Broken pipe are from
Python programs. :-)
Regards,
--
Gustavo Niemeyer
http://niemeyer.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] Fwd: Distributed RCS
Like Skip, I tried experimenting with it. While that may be the right model, I don't think it is the right software. In bazaar-ng 0.0.5 (which is what Debian unstable currently has), bzr commit would not open a text editor, but require the commit message on the command line; selective commit of only some of the changed files is also not supported. bzr diff cannot show the changes between two revisions, The development version has all of those features implemented already. and cannot show revisions across branches. I'm not sure about this one, though. -- Gustavo Niemeyer http://niemeyer.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] Fwd: Distributed RCS
I had problems finding the place where the bazaar-NG source code repository is stored - is there a public access to the HEAD version? You may use rsync: rsync -av --delete bazaar-ng.org::bazaar-ng/bzr/bzr.dev . Or bzr itself: bzr branch http://bazaar-ng.org/bzr/bzr.dev Regards, -- Gustavo Niemeyer http://niemeyer.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] Chaining try statements: eltry?
How would a PEP to *remove* this feature fare today? I hope not well, since I use them quite often. Barry also reiterated this idea and I support removing them in Python 3000. I do use them when I want to know when I break out of a loop prematurely, but I am definitely not a typical use case for experienced users since I basically learned how to program in Python so I didn't have any baggage preventing me from not remembering they existed. So you're indeed an example that learning them might not be an issue, even when no previous programming experience exists. For the case of an experienced programmer getting into Python as a new language, most of us have been there, and I remember that, when I understood what it was about, I was actually amazed rather than confused. I started wondering why it's not available in other languages. Simplifying the basic control flow mechanisms is always good. [...] Of course, it largely depends on what simplifying means to you. As a side comment, I belive that talking often and at regular intervals about builtins and syntax which may disappear from the language in the next major version is not something good. I understand that the next major is being seen as the place to break legacy compatibility, but that's the kind of thing that you (Guido) are aware that no comments besides personal likes and dislikes will be raised. If you *really* want to remove them (even though I strongly dislike the idea ;-), decide it and get just half of the complaints, rather than getting all of them and spreading FUD. -- Gustavo Niemeyer http://niemeyer.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
[Python-Dev] PyPI: no space left on device
PyPI seems to be out of space: % ./setup.py register --show-response running register Using PyPI login from /home/niemeyer/.pypirc --- Error... There's been a problem with your request psycopg.ProgrammingError: ERROR: could not extend relation releases: No space left on device HINT: Check free disk space. -- Gustavo Niemeyer http://niemeyer.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] PyPI: no space left on device
PyPI seems to be out of space: FYI, python-dev is not a good place to send messages like this. Please use [EMAIL PROTECTED] (I've already notified the appropriate parties.) Before sending the message I thought, let's see how much time it takes until someone mentions the right place to deliver the message. Adding that address to the PyPI page itself would be valueable, and will probably save python-dev from further misinformed reporters. Thanks for forwarding it this time, -- Gustavo Niemeyer http://niemeyer.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] Bug day on the 25th?
Greetings, It seems like a good idea to have another Python bug day. Saturday June 25th seems the most practical date (this coming weekend is too soon, and the weekend after is a minor holiday -- Father's Day). We'd convene in the usual place: the #pydotorg IRC channel, on irc.freenode.net. Assuming no one can think of a reason why the 25th would be unsuitable, I'll send an announcement to c.l.py.a in a few days. Not sure if that's a reason to prevent the event, since fixing bugs is a good thing no matter when, but that's two days before EuroPython, and many people might be moving to the conference at that time. -- Gustavo Niemeyer http://niemeyer.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] Thoughts on stdlib evolvement
moving the main trunk and main development over to the Python CVS is another thing, entirely. (as I've said many times before, both the user community and the developer community would benefit if the core standard library were made smaller, and more externally maintained packages were included in the standard releases) An issue to consider about this is that maintainers (not talking about you or anyone else specifically) have different concepts of stability, and while it may seem perfectly ok to refactor external modules between two stable releases, doing so in the standard library would spread fear and python is so untrustful feelings. That's something a good police, reflecting practices that we learn by osmose while living in that environment (python-dev) for a while, could try to handle. Enforcing it is another issue, of course. -- Gustavo Niemeyer http://niemeyer.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] Re: hierarchicial named groups extension to the re library
Greetings, If this kind of functionality would fall on immediate rejection for some reason, even writing the PEP might be pointless. If the [...] In my opinion the functionality is useful. I personally think that the proposed functionality should *not* live in a separate module, but somehow be integrated into SRE. Whether or [...] Agreed. I propose to integrate this functionality into the SRE syntax, so that this special kind of group may be used when explicitly wanted. This would avoid backward compatibility problems, would give each regular expression a single meaning, and would allow interleaving hierarchical/non-hierarchical groups. I offer myself to integrate the change once we decide on the right way to implement it, and achieve consensus on its adoption. Best regards, -- Gustavo Niemeyer http://niemeyer.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] hierarchicial named groups extension to the re library
Greetings Chris,
Well, that would be something I'd want to discuss here. As I'm not
sure if I actually ~want~ to match the API of the re module.
If this feature is considered a good addition for the standard
library, integrating it on re would be an interesting option.
But given what you say above, I'm not sure if *you* want to
make it a part of re itself.
[...]
IMO If you don't bother to name a group then you probably aren't going
to be interested in it anyway - so why keeping a reference to it?
That's not true. There's a lot of code out there using unnamed
groups genuinely. The syntax (?: ) is used when the group content
is considered unuseful.
If you only wanted to extract the numbers from those verses...
regex='^(((?Pnumber\d+) ([^,]+))(, )?)*$'
pat2=re2.compile(regex)
x=pat2.extract(buf)
x
{'number': ['12', '11', '10']}
Before the compression stage the _Match object actually looked like this:
{'_group0': {'_value': '12 drummers drumming, 11 pipers piping, 10
lords
[...]
'10'}}]}}
But the compression algorithm collected the named groups and brought
them to the surface, to return the much nicer looking:
{'number': ['12', '11', '10']}
I confess I didn't thought about how that could be cleanly
implemented, but both outputs you present above look inadequate
in my opinion. Regular expressions already have a widely adopted
meaning. If we're going to introduce new features, we should try
to do that without breaking the current well known meanings they
have.
I find the feature very interesting, but being used to live without it,
I have difficulty evaluating its usefulness.
Yes - this is a good point too, because it ~is~ different from the re
library. re2 aims to do all that searching, grouping, iterating and
collecting and constructing work for you.
[...]
Actually, I ~would~ like to limit it to just named groups.
I reckon, if you're not going to bother naming a group, then why would
you have any interest in it.
I guess its up for discussion how confusing this new way of thinking
could be and what drawbacks it might have.
Your target seems to be a new kind of regular expressions indeed.
In that case, I'm not sure if re2 is the right name for it, given
that you haven't written an improved SRE, but a completely new
kind of regular expression matching which depends on SRE itself
rather than extending it on a compatible way.
While I would like to see *some* kind of successive matching
implemented in SRE (besides the Scanner which is already available),
I'm not in favor of that specific implementation.
I'm open to discuss that further.
--
Gustavo Niemeyer
http://niemeyer.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
[Python-Dev] Re: SRE bug and notifications
Is there any way to get notified about certain kinds of bugs in SourceForge? Or, is there any way to follow all new bugs posted? Or even, what's the easiest way to avoid that problem by being notified of bugs as soon as possible? After some googling I've found python-bugs-list. Mentioning it in http://www.python.org/community/lists.html might be a good idea. Additional suggestions still accepted. Thanks! -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
